L’automatisation ACME ne remplace pas la surveillance des certificats
ACME constitue une base adaptée aux certificats TLS publics de courte durée. Il automatise l’émission et le renouvellement. À lui seul, il n’inventorie pas tous les certificats publics et internes, n’identifie pas l’équipe responsable et ne garantit pas que chaque actif dispose d’un circuit d’alerte permettant d’agir.
Ce qu’ACME résout réellement
La RFC 8555 définit ACME comme un protocole qu’une autorité de certification et un demandeur peuvent utiliser pour automatiser la validation des identifiants et l’émission des certificats. Ce point est important : sans automatisation, le raccourcissement de la durée de vie des certificats devient irréaliste sur le plan opérationnel.
ACME Renewal Information, normalisé par la RFC 9773, améliore le renouvellement. Un serveur ACME peut proposer des fenêtres de renouvellement, et un client peut signaler qu’il a correctement renouvelé et remplacé un certificat. Let’s Encrypt recommande de consulter fréquemment ARI et, lorsque c’est possible, de l’utiliser à la place d’un calendrier de renouvellement codé en dur.
ACME couvre
- Demande d’un certificat auprès d’un serveur ACME.
- Démontrer le contrôle des identifiants au moyen des types de défis pris en charge.
- Recevoir le certificat émis et, selon le client, le renouveler automatiquement.
- Fonctions de révocation et de gestion des certificats au niveau du compte.
La surveillance doit encore vérifier
- Quel certificat est réellement présenté sur chaque hôte, port et nom SNI.
- Quels points de terminaison publics et internes, fichiers et objets TLS Kubernetes se trouvent dans le périmètre de l’inventaire.
- Si la chaîne, l’émetteur, l’ensemble des SAN, le type de clé ou les règles TLS ont changé de manière inattendue.
- Quelle équipe est responsable du point de terminaison et quel circuit d’alerte peut corriger le problème avant la fin de la fenêtre de renouvellement.
- Quels certificats internes, points de terminaison de PKI privée et certificats installés manuellement se trouvent en dehors du parcours ACME.
Le périmètre de surveillance s’étend au-delà de la délivrance
La limite essentielle est simple : ACME peut indiquer qu’un certificat a été émis ou renouvelé. Il ne peut pas inventorier tous les points de terminaison auxquels accèdent les utilisateurs et les systèmes internes, ni tous les certificats stockés sur un hôte privé ou dans un cluster en dehors de ce processus ACME.
Cette distinction devient plus importante à mesure que la durée de vie des certificats diminue. Le renouvellement cesse d’être une tâche trimestrielle inscrite au calendrier et devient une boucle normale de l’infrastructure. Une boucle fiable nécessite l’automatisation de l’émission, celle du déploiement et une observation indépendante.
Les modes de défaillance que l’automatisation ne supprime pas
Actifs en dehors du chemin ACME
Les VPN, équipements, API privées, certificats installés manuellement et PKI internes peuvent rester en dehors de l’inventaire automatisé comme de son circuit d’alerte.
Automatisé en un seul endroit
Le serveur web public est automatisé, mais le VPN, l’équipement, l’interface d’administration, l’API interne ou le point de terminaison propre à un client restent gérés manuellement.
Aucun responsable en cas de panne
La tâche de renouvellement relève d’une équipe, le point de terminaison d’une autre, et l’alerte arrive dans une boîte partagée que personne ne considère comme opérationnelle.
Hypothèses de renouvellement erronées
Un calendrier codé en dur ou le comportement d’un ancien client peut fonctionner avec des certificats de 90 jours, puis devenir fragile à mesure que leur durée de vie diminue et que les fenêtres de renouvellement évoluent.
Un modèle opérationnel pratique
- Utilisez ACME pour l’émission et le renouvellement partout où le point de terminaison et l’autorité de certification le prennent en charge.
- Utilisez des clients compatibles ARI lorsqu’ils sont disponibles afin que l’autorité de certification puisse signaler les fenêtres de renouvellement suggérées et la nécessité d’un remplacement anticipé.
- Surveillez directement le point de terminaison, indépendamment du client ACME.
- Suivez les responsables, les destinations des alertes, les sources observées et les méthodes de renouvellement pour chaque certificat.
- Intégrez au même inventaire opérationnel les certificats internes et les points de terminaison qui n’utilisent pas un service ACME public.
- Déclenchez les alertes d’après ce que les utilisateurs et les systèmes voient réellement, pas seulement d’après la réussite de la tâche d’émission.
La place de Nocert
Nocert ne remplace ni les clients ACME, ni les autorités de certification, ni l’automatisation du déploiement. Il surveille les certificats présentés par les points de terminaison TLS publics et internes accessibles, puis réunit dans le même inventaire les découvertes du système de fichiers et de Kubernetes. Les équipes peuvent ainsi suivre l’expiration des actifs gérés ou non par ACME. Les espaces de travail Business et Custom ajoutent aussi l’état des règles Compliance.
Nocert intervient donc aux côtés d’ACME, pas à sa place. Le modèle consiste à confier l’émission et le renouvellement à ACME, puis à confirmer le résultat sur les points de terminaison importants au moyen d’une surveillance indépendante.
Sources primaires
Cette note s’appuie sur la norme ACME, l’extension ACME Renewal Information, le guide d’intégration de Let’s Encrypt et sa documentation relative aux limites de requêtes.
- RFC 8555 : environnement de gestion automatique des certificats
- RFC 9773 : extension ACME Renewal Information
- Guide d’intégration Let’s Encrypt
- Limites de requêtes de Let’s Encrypt et exemptions ARI pour les renouvellements
- Note de Nocert sur le raccourcissement de la durée de vie des certificats TLS