Let’s Encrypt ACME : automatiser la gestion des certificats et contrôler les renouvellements en toute sécurité

Processus ACME et rôles de clés distincts

ACME normalise la communication entre un client et l'autorité de certification, et non l'ensemble de l'environnement d'exploitation. Le client utilise d'abord un compte ACME, puis crée une commande pour un ou plusieurs noms de domaine. Pour chaque identifiant, le serveur exige une autorisation. Ce n'est qu'une fois celle-ci obtenue que le client peut finaliser la commande à l'aide d'une demande de signature de certificat (Certificate Signing Request, ou CSR) et récupérer le certificat émis.

1. Créez une clé de compte ou utilisez un compte ACME existant, puis créez l'ordre.
2. Pour chaque identifiant demandé, fournir le défi spécifié et attendre l'autorisation.
3. Générer une paire de clés distincte pour le certificat, créer la CSR à partir de celle-ci et finaliser la commande. La clé publique figurant dans la CSR ne doit pas correspondre à la clé du compte utilisée pour authentifier la demande de finalisation.
4. Récupérer le certificat et la chaîne de certificats, les stocker en toute sécurité et les distribuer aux points de terminaison TLS prévus à cet effet.

Le Clé de compte ACME authentifie le client auprès du serveur ACME pour le compte et signe les messages du protocole. La clé privée utilisée dans la CSR fait en revanche partie de l'identité TLS ultérieure. La norme RFC 8555 exige deux classes de clés distinctes : la clé publique de la CSR ne doit pas correspondre à une clé de compte connue et, en particulier, ne doit pas être identique à la clé de compte qui authentifie la demande de finalisation. Le client et le serveur doivent vérifier cette séparation.

Dans le cas de DNS-01, un troisième élément sensible vient s’ajouter : l’autorisation d’accès à l’API DNS. Let’s Encrypt souligne que la présence d’identifiants complets d’accès à l’API DNS sur un serveur web augmente considérablement les conséquences d’une attaque. À titre de mesure de sécurité opérationnelle, le jeton ne devrait donc, dans la mesure du possible, être autorisé à modifier que les enregistrements de défi nécessaires ; sinon, la validation DNS peut être effectuée sur un système distinct.

Les clés de compte, les clés de certificat et l'accès DNS constituent des domaines de confiance distincts. L'utilisation de paires de clés différentes pour le compte et le certificat est une exigence du protocole ; leur stockage séparé, des droits d'accès strictement limités et des processus de rotation indépendants constituent en outre des mesures opérationnelles importantes. Ainsi, un jeton DNS compromis ne doit pas nécessairement signifier un accès à la clé privée du certificat ni au compte ACME.

L'automatisation ne résout pas les problèmes liés à des conditions préalables erronées. Un port inaccessible, un routage incorrect, une délégation DNS inadaptée ou des droits d'accès trop étendus restent des problèmes opérationnels, même si la création des commandes est automatisée. ACME accélère le processus reproductible ; les opérateurs doivent mettre en œuvre de manière fiable dans leur environnement un concept de droits, la séparation obligatoire entre les clés de compte et les clés de certificat, un stockage sécurisé ainsi que le contrôle des certificats effectivement délivrés.

Le défi idéal pour l'infrastructure

Le « Challenge » détermine la manière dont une autorité de certification vérifie le contrôle d'un identifiant. Il doit donc être dérivé du chemin réseau, de la gestion DNS et de la terminaison TLS, et non d'une préférence générale pour un outil client. Les spécifications HTTP-01, DNS-01 et TLS-ALPN-01 décrivent différents types de contrôle et imposent donc des exigences différentes en matière d'infrastructure et d'autorisations.

Pour un site web unique et accessible au public, HTTP-01 c'est généralement la méthode la plus directe. Le client met une ressource à disposition sous /.well-known/acme-challenge/ prête, qui récupère Let’s Encrypt via le port 80. Si un domaine pointe vers plusieurs cibles A ou AAAA, cette ressource doit être accessible sur tous les systèmes susceptibles d’être interrogés par la requête de validation. Dans le cas contraire, une erreur de validation survient de manière sporadique.

Certificats génériques pour *.example.org exigent en revanche impérativement DNS-01. Pour cela, le client publie un enregistrement TXT à l'adresse _acme-challenge.example.org. Cela convient à de nombreux sous-domaines dynamiques, à des serveurs web distribués ou à un équilibreur de charge, car aucune instance HTTP spécifique n'a besoin de fournir le fichier de validation. Cela nécessite toutefois une modification DNS fiable et automatisable.

Un proxy inverse dont le port 80 n'est pas utilisable peut TLS-ALPN-01 l'utiliser, à condition qu'il contrôle la terminaison TLS sur le port 443 et que le client utilisé prenne en charge ce défi. La validation s'effectue via une connexion TLS spécifique, et non via un fichier Web standard. Cette méthode est donc particulièrement adaptée aux infrastructures de proxy ou d'hébergement spécialisées, mais ne constitue pas un substitut général à HTTP-01. Les caractères génériques ne sont pas pris en charge ici non plus.

Aucune méthode n'est supérieure en général : HTTP-01 réduit l'accès au DNS pour un site web simple, DNS-01 permet l'utilisation de caractères génériques et dissocie la validation du chemin d'accès web, tandis que TLS-ALPN-01 exploite de manière ciblée les contrôles TLS existants. Il est essentiel que le « challenge » choisi fonctionne dans des conditions réelles de basculement, sur des chemins IPv4 et IPv6, et que ses autorisations soient adaptées au modèle d'exploitation concerné.

ARI, profils et durées plus courtes

Avec Informations sur le renouvellement ACME (ARI), la logique de renouvellement passe d'une date butoir fixée localement à une plage horaire recommandée par le serveur ACME. Le client interroge cette information pour un certificat existant et choisit un moment aléatoire au sein de cette fenêtre. Cela permet d'étaler les renouvellements dans le temps et de les anticiper de manière ciblée en cas d'événements particuliers.

ARI est une extension standardisée, mais ce n'est pas une fonctionnalité automatique de tous les clients ou panneaux d'hébergement installés. Let’s Encrypt peut proposer de nouvelles fonctionnalités ACME rétrocompatibles sur le point de terminaison existant ; leur utilisation par une installation spécifique dépend de sa version et de sa mise en œuvre. Pour les parcs importants, il convient donc de vérifier si le client interroge ARI, respecte la fenêtre temporelle et ne resynchronise pas les renouvellements.

Let’s Encrypt associe également les commandes à des profils de certificat. En l’absence de choix explicite, le profil classique est sélectionné par défaut et a actuellement une durée de validité de 90 jours. Le profil tlsserver a une durée de validité de 45 jours, des délais plus courts pour les autorisations et les ordres ouverts, ainsi qu'un maximum de 25 noms DNS. shortlived utilise également des durées de vie courtes pour les objets, est valable environ 160 heures et prend en charge les identifiants DNS et IP.

La sélection des profils nécessite également la prise en charge par le client ; elle ne doit pas être déduite uniquement à partir de la documentation du serveur. Outre leur durée de validité et leurs identifiants, les profils se distinguent également par d’autres caractéristiques. Les applications et les outils d’inventaire ne doivent donc pas supposer tacitement un déroulement uniforme ni la présence d’un nom commun dans chaque certificat.

D'un point de vue mathématique, le rapport entre 90 jours et environ 160 heures correspond à un facteur d'environ 13,5 en termes de durée. Cela n'implique pas de charge mesurable, mais une conséquence claire en matière de planification : toute perturbation au niveau de la commande, de la distribution ou du rechargement entraîne certificats à court terme beaucoup plus tôt. Ils ne sont pertinents que pour les systèmes dont l'ensemble de la chaîne d'approvisionnement est surveillée et dont le renouvellement ne dépend pas d'interventions manuelles. Pour les renouvellements coordonnés par l'ARI, Let’s Encrypt applique des règles spécifiques concernant les limites de requêtes, sous certaines conditions documentées.

Matrice de défis et délégation DNS sécurisée

Le choix du défi dépend des infrastructures disponibles, et non d'un classement général. HTTP-01 nécessite une réponse accessible au public via le port 80, DNS-01 une entrée TXT vérifiable et TLS-ALPN-01 le contrôle de la terminaison TLS sur le port 443. Les noms génériques ne peuvent être validés qu'avec DNS-01.

Un site web hébergé sur un seul serveur web est donc souvent bien desservi par HTTP-01. Cependant, si les enregistrements DNS de type A ou AAAA pointent vers plusieurs systèmes, chaque destination effectivement atteinte doit fournir la ressource attendue. Sinon, le résultat dépend du point de terminaison atteint par la validation. Un équilibreur de charge ou un référentiel de défis synchronisé de manière centralisée ne résout ce problème que s’il couvre tous les chemins.

Pour le DNS-01, on utilise comme Autorisation minimale Viser à ce que le client ACME ne puisse modifier que les entrées de défi nécessaires. La restriction effectivement possible dépend de l'API et du modèle d'autorisation du fournisseur DNS ; tous les services n'accordent pas de droits pour un nom TXT individuel. Si seul un accès étendu est disponible, il convient de transférer la validation vers un système distinct ou de déléguer une zone « challenge » séparée. Les identifiants d’accès doivent être conservés dans un référentiel sécurisé, séparément des clés de certificat et des clés de compte ACME.

Dans le cas de zones étendues, une zone « Challenge » distincte peut restreindre davantage les droits. La délégation de _acme-challenge La migration via CNAME ou NS transfère les données de validation vers un espace d'administration dédié. Le client ne dispose alors de droits de modification que dans cet espace. Avant la mise en production, il convient de vérifier le contenu des enregistrements TXT et la résolution DNS : une réponse API correcte ne suffit pas si les résolveurs ne voient pas encore la délégation ou l'enregistrement.

Automatiser de manière fiable la mise à jour et la distribution

Résistant Gestion des certificats ne s'arrête pas à la récupération d'un certificat. Dans un environnement distribué, un worker ACME central déclenche la validation et stocke le certificat ainsi que la clé privée de manière sécurisée. Ce n'est qu'ensuite que ces éléments sont distribués aux points d'extrémité TLS, où ils sont vérifiés et activés de manière contrôlée. La clé de certificat utilisée dans la CSR doit être différente de la clé du compte ACME servant à l’authentification ; la manière dont ces deux clés sont ensuite stockées séparément, autorisées et renouvelées doit être définie dans le concept d’exploitation.

Le tableau suivant décrit un concept opérationnel recommandé pour la chaîne logistique. La norme RFC 8555 exige que la clé publique de la CSR ne corresponde à aucune clé de compte connue et, en particulier, qu’elle ne coïncide pas avec la clé de compte utilisée pour l’authentification de l’ordre de finalisation. La séparation organisationnelle concrète entre le stockage, les droits d’accès et la rotation repose sur cette exigence du protocole. Le « Deploy Hook » de Certbot est prévu pour les actions à effectuer après la délivrance réussie du certificat. La sécurisation de la transmission, la vérification de la destination et la vérification TLS externe doivent être adaptées à l’infrastructure concernée.

Pour toute modification apportée aux intégrations Panel ou DNS, la chaîne de production ne doit pas être considérée comme un système isolé. En particulier en cas de gestion via Mises à jour de Plesk pour les hébergeurs Les fonctionnalités disponibles dépendent du support de panneau, des extensions et des services connectés. Les capacités concrètes du client ACME, par exemple pour les extensions de protocole supplémentaires, dépendent également de la version et doivent être vérifiées dans la configuration utilisée.

Avec Certbot, un « deploy hook » peut déclencher la dernière étape, car il ne s'exécute qu'après un renouvellement réussi. L'exemple suivant part du principe que le chemin d'accès local correspond à un script exécutable et validé, ne contenant aucune information d'identification. Le script doit idempotent travailler, consigner les erreurs et ne recharger que les services qui utilisent le certificat mis à jour.

certbot renew --deploy-hook /usr/local/sbin/reload-tls-services

Le code de sortie de certbot renew ne constitue pas une preuve de l'existence d'un nouveau certificat : même s'il n'y avait rien à renouveler, la commande peut se terminer avec le statut 0. Le système de surveillance doit donc déterminer de manière indépendante quel certificat le point de terminaison public fournit réellement, quand il expire et si le rechargement a réussi.

CAA, profils et certificats pour les adresses IP

Un enregistrement CAA est un Garde-corps d'exposition: Elle définit quels organismes de certification sont autorisés à délivrer des certificats pour un domaine. De plus, la politique peut spécifier la méthode de validation autorisée et, via le paramètre accounturi Définir le compte ACME prévu. La clé de compte actuelle authentifie l'accès à ce compte, mais peut être modifiée via le processus ACME Key Change. L'association au compte ne remplace donc ni la protection offerte par la clé de compte actuelle, ni un système complet de gestion des autorisations.

La ligne d'enregistrement suivante autorise Let’s Encrypt pour le domaine uniquement avec la validation DNS-01. Elle ne convient que si la validation DNS-01 est configurée de manière automatisée et si la zone de défi est gérée de manière fiable. Si vous souhaitez utiliser ultérieurement HTTP-01 pour un site web spécifique ou TLS-ALPN-01 pour un proxy inverse, vous bloquez délibérément cette émission en appliquant la restriction indiquée.

example.org. CAA 0 issue "letsencrypt.org;validationmethods=dns-01"

Une ligne ne décrit pas nécessairement l'intégralité de la Politique de la CAA de la zone. Plusieurs enregistrements du même type ont un effet cumulatif : si l'un d'entre eux autorise l'émission, cette autorisation peut prévaloir malgré des enregistrements ultérieurs plus restrictifs. Pour les certificats à caractères génériques, il convient en outre de vérifier si issuewild-des enregistrements existent. En l'absence de tels enregistrements, on a issue y compris les caractères génériques ; existants issuewild- Les entrées régissent en revanche séparément l'attribution des caractères génériques. C'est donc toujours l'ensemble complet et valide des enregistrements associés au nom vérifié qui fait foi.

Les certificats pour les adresses IP publiques constituent un cas à part par rapport aux certificats de domaine. Let’s Encrypt prend en charge les identifiants IP dans le profil shortlived; les méthodes HTTP-01 et TLS-ALPN-01 peuvent être utilisées pour la validation. La méthode DNS-01 ne permet pas de valider une adresse IP. La courte durée de validité, d'environ 160 heures, nécessite donc un renouvellement, une distribution et un contrôle de livraison automatisés et continus.

Le profil « shortlived » ne convient donc aux interfaces directement accessibles par IP que si chaque étape fonctionne sans intervention manuelle. Il ne s'agit pas d'une variante simplifiée destinée aux systèmes entretenus de manière occasionnelle. De plus, le client ACME utilisé et l'environnement cible doivent prendre en charge le profil choisi ainsi que le « challenge » sélectionné ; la disponibilité au niveau du service ACME ne garantit pas la prise en charge par toutes les versions du client.

Surveillance et dépannage, d'abord dans l'environnement de staging

Le dépannage avec ACME commence par la procédure de validation effectivement utilisée, et non par une nouvelle demande de certificat. Pour les modifications apportées au client, au routage, au pare-feu ou au DNS, il est recommandé d’utiliser le point de terminaison de test distinct de Let’s Encrypt. L’environnement de test dispose de limites propres, nettement plus élevées, mais celles-ci ne sont pas illimitées ; les certificats de test qui y sont émis ne sont pas considérés comme fiables par le public. Même si de nouvelles fonctionnalités de protocole peuvent être disponibles sur le point de terminaison ACME, la prise en charge par le client installé doit néanmoins être vérifiée séparément.

Dans le cas d'une erreur HTTP-01, il faut d'abord vérifier si le domaine concerné est accessible au public via le port 80 et si le fichier demandé se trouve à l'adresse /.well-known/acme-challenge/ au système cible. La présence de plusieurs enregistrements A ou AAAA rend le test plus complexe : chaque point de terminaison effectivement accessible doit fournir le fichier de défi correspondant. Les causes typiques sont un routage d'hôte virtuel divergent, un proxy en amont, une règle de pare-feu ou des conteneurs non synchronisés.

TLS-ALPN-01 exige en revanche un contrôle de la terminaison TLS sur le port 443. En cas d'erreur, il convient de vérifier quel équilibreur de charge ou proxy accepte la connexion, s'il fournit le certificat nécessaire au défi et si un service TLS standard prend le pas sur le processus. La création réussie d’un fichier de certificat local ne prouve pas que le point de terminaison public le utilise.

Pour DNS-01, le nom et le contenu de l'enregistrement TXT se trouvent sous _acme-challenge à contrôler séparément. L'enregistrement doit être publié dans la zone déléguée ou de référence ; de plus, la chaîne de délégation doit être correcte si une zone de challenge distincte est utilisée. Les échecs répétés dus à des fautes de frappe, à des modifications non encore visibles ou à une délégation erronée doivent d'abord être analysés dans l'environnement de test.

Efficace Suivi Il ne se contente pas de surveiller la date d'expiration dans le répertoire de l'ACME-Worker. Il vérifie de manière indépendante le nom d'hôte fourni, la durée de validité restante du certificat qui y est présenté et la réussite du rechargement après une mise à jour. Une alerte doit également être déclenchée si un renouvellement échoue ou si un terminal continue de fournir l’ancien certificat malgré une émission réussie. Pour les modifications prévues sur les serveurs d’hébergement, l’article précise Planifier les mises à jour de cPanel et WHM en toute sécurité la planification opérationnelle nécessaire.

Limites tarifaires et renouvellements dans le portefeuille

Dans un portefeuille de certificats, les limites de taux constituent une contrainte de conception de la Automatisation SSL. Les renouvellements forcés quotidiens ou les tâches lancées simultanément génèrent des commandes inutiles et peuvent déclencher des limitations. Cela vaut particulièrement lorsqu’une défaillance de l’infrastructure affecte simultanément de nombreux domaines : les répétitions ne corrigent ni les fichiers de défi manquants ni les paramètres DNS erronés, mais augmentent le nombre de validations ayant échoué. Les erreurs doivent donc être identifiées et corrigées avant la prochaine exécution en production.

Informations sur le renouvellement ACME, en bref ARI, remplace les seuils locaux fixes par une fenêtre de renouvellement recommandée par le serveur ACME pour un certificat existant. Le client compatible ARI interroge les informations de renouvellement et choisit un moment aléatoire au sein de cette fenêtre. Un planificateur peut lancer le client régulièrement, mais n’évalue pas lui-même les informations ARI. Le client doit prendre en compte la fenêtre recommandée et Retry-After en tenir compte et, en cas d'erreurs, respecter des intervalles de retrait et de réessai appropriés. Des exécutions plus fréquentes du planificateur ne doivent donc pas entraîner de réessais incessants des tâches ayant échoué.

Pour Let’s Encrypt, les renouvellements coordonnés par l’ARI peuvent être exemptés des limites de débit, sous réserve des conditions documentées. La nouvelle demande doit notamment contenir au moins un identifiant du certificat à remplacer, et celui-ci ne doit pas avoir déjà été remplacé via ARI. Il ne s’agit pas d’une autorisation générale pour toutes les nouvelles demandes : les modifications apportées à la portée du certificat doivent être traitées séparément sur le plan technique et opérationnel.

En particulier, une liste SAN raccourcie ou modifiée n'entraîne pas automatiquement le renouvellement du certificat existant. Une demande ne comportant qu'une partie des noms existants peut générer un certificat distinct, tandis que l'ancien reste valable. L'inventaire doit donc recenser l'identifiant du certificat, la liste complète des identifiants, les points de terminaison associés et la procédure de renouvellement. Avant toute modification prévue de la liste SAN, il convient de déterminer quels services seront mis à jour et quand les certificats qui ne sont plus nécessaires seront supprimés.

Lorsqu'il y a plusieurs workers, une attribution claire des responsabilités permet d'éviter les commandes en double pour un même stock. Il est judicieux de mettre en place un planificateur central ou un verrouillage coordonné, des journaux traçables et des tentatives échelonnées après une erreur. La sélection aléatoire au sein d’une fenêtre ARI ne remplace pas ce mécanisme de contrôle, mais réduit avant tout la simultanéité des renouvellements réguliers.

Choisir le modèle d'exploitation adapté en fonction du risque

Pour un site web unique et accessible au public, le modèle HTTP-01 est généralement le plus simple. Le serveur web doit gérer le port 80 de manière fiable et fournir le fichier de défi à l'emplacement attendu. Ce modèle n'est pas compatible avec les caractères génériques et devient fragile lorsque plusieurs cibles indépendantes répondent au même domaine. Il est donc particulièrement pertinent lorsque le routage Web, le stockage des certificats et la fourniture du protocole TLS sont regroupés en un seul et même endroit clairement contrôlé.

DNS-01 est le modèle idéal pour les caractères génériques, les sous-domaines dynamiques et les points de terminaison TLS distribués. La condition préalable n’est pas simplement un accès au DNS, mais la possibilité de modifier de manière sécurisée et automatisée l’enregistrement TXT requis. Un jeton aussi restreint que possible ou une zone de défi déléguée réduit les conséquences d’un système compromis. Le niveau de granularité atteignable dépend de l’API DNS. Les délégations doivent être documentées en tant que dépendance opérationnelle, surveillées et accompagnées d’un plan de reprise.

TLS-ALPN-01 convient aux opérateurs qui souhaitent contrôler de manière ciblée la terminaison TLS sur le port 443, par exemple au niveau d'un proxy inverse ou d'un équilibreur de charge. Cette méthode ne remplace pas systématiquement HTTP-01 et ne prend pas en charge les caractères génériques. Son utilité pratique dépend en outre de l'implémentation spécifique du client et du proxy. Avant toute mise en œuvre, il convient donc de vérifier si le logiciel est capable de générer le challenge, de le transmettre et de le supprimer correctement une fois l'opération terminée.

Le Profil « shortlived » ne convient qu’aux systèmes dotés d’une automatisation de bout en bout sans faille. Let’s Encrypt prévoit pour cela une durée d’environ 160 heures ainsi que des identifiants DNS et IP ; par rapport au profil standard de 90 jours, cela augmente considérablement, d’un point de vue mathématique, la fréquence de renouvellement nécessaire. Chaque étape, de la commande à la distribution, en passant par le rechargement et le contrôle externe, doit donc fonctionner de manière fiable. Le choix d’un profil suppose en outre que le client ACME utilisé prenne effectivement en charge ce profil.

Quel que soit le modèle, il faut un équipement professionnel Gestion des certificats un inventaire complet, des clés gérées en toute sécurité et des accès DNS aux droits d'accès minimaux. La clé de compte authentifie le client pour le compte ACME ; la clé privée utilisée dans la CSR fait partie de l'identité TLS. La norme RFC 8555 interdit d’utiliser la clé publique du compte dans un certificat : la clé figurant dans la CSR ne doit notamment pas correspondre à la clé du compte qui authentifie la demande de finalisation. Le stockage séparé, l’attribution des autorisations et la rotation de ces classes de clés, ainsi que des accès révocables et une procédure de retour testée vers le certificat précédent, font partie du concept de gestion des droits et de gestion des urgences.

Une exécution réussie d'ACME ne doit pas être le seul critère de réussite. Le contrôle de distribution doit déterminer, en dehors du worker, quel certificat est présenté par un véritable point de terminaison TLS. Pour les étapes de distribution et de rechargement, il convient d’utiliser des actions qui ne sont déclenchées qu’après un renouvellement réussi ; Certbot prévoit à cet effet un « deploy hook ». Son script doit être idempotent, consigner les erreurs et ne recharger que les services qui utilisent effectivement les certificats renouvelés.