Renouvellement des certificats SSL/TLS : automatisation, cas rebelles et seuil d'achat

⚡TL;DR

• Les renouvellements ne consomment pas le quota Let's Encrypt de 50 certificats par domaine enregistré. Cette limite mesure l'entrée de nouveaux noms, pas la taille d'un parc. Croire l'inverse fausse tout dimensionnement.
• Ce qui casse un renouvellement de certificat SSL n'est presque jamais ACME, mais les endpoints qu'aucun script ne recharge : boîtiers à interface web, keystores à mot de passe interactif, terminaisons TLS managées sans API.
• Un inventaire se tient par couple (hôte, port), pas par nom d'hôte. Sur une même adresse IP, ldap.google.com rend à un client par défaut deux numéros de série différents sur les ports 389 et 636, et un scanner qui oublie le SNI enregistre un troisième serial, stable et faux.
• ACME, ARI et les six phases du cycle de vie sont ici tenus pour acquis : ils sont traités dans le guide de gestion du cycle de vie des certificats.

Le renouvellement d'un certificat SSL échoue rarement là où on l'attend. Le mode de panne le plus courant n'est pas une erreur d'émission bien visible dans un journal : c'est un certbot renew qui tourne vert pendant des semaines alors que le service continue de présenter l'ancien certificat. Deux lignes d'openssl le détectent : le numéro de série lu sur le disque contre celui réellement servi sur le port. Rien, dans les journaux du client ACME, ne le fera à votre place. Les sorties réelles sont plus bas.

Le contexte durcit la mécanique. Au 21 juillet 2026, un certificat TLS public ne peut pas dépasser 200 jours de validité, et la même limite s'applique à la réutilisation de la validation de contrôle de domaine. Les paliers suivants tombent en mars 2027 puis en mars 2029, et le second découple validité et revalidation. Le pourquoi de ce calendrier est traité dans notre article sur la réduction à 47 jours. Ici, on parle du comment : ce qui casse concrètement quand la fréquence monte, et ce qu'on met en face.

Ce playbook s'adresse aux équipes qui gèrent entre 50 et 1 000 certificats sur un parc hétérogène, sans équipe PKI dédiée. Vous y trouverez des commandes exécutées et leurs sorties réelles, les pièges qui les accompagnent, et les endroits où nous n'avons rien pu mesurer, dits comme tels. Pas de comparatif d'éditeurs. Un seul critère d'achat, chiffré, et il ne porte pas sur le nombre de certificats.

Expiration des certificats SSL en 2026 : le palier en vigueur et ce que ça change pour vos scripts

Au 21 juillet 2026, le palier applicable est celui entré en vigueur le 15 mars 2026. Il tient en trois plafonds : 200 jours de validité maximale, 200 jours de réutilisation de la validation de contrôle de domaine (DCV) et 398 jours de réutilisation des informations d'identité de l'abonné (SII). C'est le plafond dur des Baseline Requirements du CA/Browser Forum.

En pratique, les autorités de certification émettent en dessous. Le texte recommande de ne pas dépasser 199 jours et n'interdit qu'au-delà de 200, si bien que la marge opérationnelle est prise par tout le monde. DigiCert a cessé d'accepter les demandes de certificats TLS publics d'une validité supérieure à 199 jours le 24 février 2026, environ trois semaines avant l'échéance. Sectigo a suivi le 12 mars 2026 : 199 jours de validité pour tout certificat TLS émis ou réémis, 198 jours de réutilisation DCV.

La suite est déjà datée. Au 15 mars 2027, la validité maximale et la réutilisation DCV passent toutes deux à 100 jours. Au 15 mars 2029, la validité tombe à 47 jours et la réutilisation DCV à 10 jours. Le SII, lui, reste fixé à 398 jours sur tout le calendrier : sa seule marche est celle du 15 mars 2026.

Attention au raccourci le plus répandu : en 2029, ce n'est pas la validité qui tombe à 10 jours, c'est la réutilisation de la preuve de contrôle du domaine. Les deux compteurs se séparent, et c'est précisément là que ça change tout pour vos scripts. Aujourd'hui, une validation réussie couvre plusieurs renouvellements consécutifs. En 2029, chaque réémission traînera derrière elle une revalidation complète, parce que la preuve précédente aura expiré depuis longtemps. Automatiser l'émission ne suffira plus. Il faudra que la validation soit automatisée en permanence, donc que les droits d'écriture DNS ou l'accès au port 80 soient disponibles en continu, et pas seulement le jour où un humain planifie un changement.

Inventorier un parc de certificats : quatre sources, quatre angles morts

Aucune source d'inventaire ne voit l'ensemble d'un parc. Les journaux de transparence listent ce qui a été émis publiquement, le disque et les magasins listent ce qui est installé, le scan réseau lit ce qui est servi, et les API des fournisseurs couvrent ce que les trois autres ne voient pas. Il faut les croiser, et surtout savoir ce que chacune rate.

Les journaux de transparence montrent ce qui a été émis, pas ce qui tourne

Les journaux de Certificate Transparency recensent tout certificat émis par une autorité publique pour vos domaines. Ils ne disent ni où il est déployé, ni s'il est encore en service. La requête naïve tient en une ligne :

curl -s 'https://crt.sh/?q=%25.captaindns.com&output=json' | jq -r '.[].name_value' | sort -u

Sur notre domaine, elle a rendu 12 valeurs uniques en 54 secondes. Une exécution précédente avait renvoyé trois HTTP 502 consécutifs avant d'aboutir à la quatrième tentative. Rien de cassé dans la commande : crt.sh répond comme ça.

Ce qui suit a été rencontré à l'exécution, pas déduit. Le -s masque l'échec : jq reçoit du HTML et sort jq: parse error: Invalid numeric literal at line 1, column 7, et sans set -o pipefail le script continue comme si de rien n'était. Les 54 secondes sont un temps de réponse nominal pour 142 certificats, pas une limitation de débit. Le %25 encode le joker %, qui couvre les sous-domaines mais pas l'apex. Le champ name_value contient des retours à la ligne quand le certificat porte plusieurs SAN : 142 objets JSON ont produit 158 lignes pour 12 valeurs uniques, ce qui rend le sort -u obligatoire. Enfin, les certificats expirés sont inclus par défaut : 76 des 142 entrées.

La version durcie corrige tout ça :

curl -sS --fail --retry 8 --retry-all-errors --retry-delay 5 --max-time 180 \
  -o crt.json 'https://crt.sh/?q=%25.captaindns.com&output=json&exclude=expired' \
&& jq -r '.[].name_value' crt.json | sed 's/^\*\.//' | tr 'A-Z' 'a-z' | sort -u

Sortie réelle : code 0 en 41,9 secondes, nouvelles tentatives comprises, 66 entrées contre 142 sans le filtre serveur, et 11 noms. Deux variantes ont été testées et rejetées, et ce sont elles qui apprennent le plus. Sans -o, sortie sur stdout, curl concatène le corps du 502 avec celui du 200 réussi : 8 342 octets qui commencent par <html><head><title>502 Bad Gateway</title> suivis du JSON valide, et jq échoue. Avec -o, curl rembobine le fichier à chaque tentative. Et --fail --retry 8 sans --retry-all-errors ne retente pas : curl 8.7.1 remonte curl: (56), code absent de la liste des erreurs que curl retente par défaut. Échec en 0,12 seconde.

Reste l'angle mort structurel : la transparence ne voit que la PKI publique. Vos certificats internes n'y figurent pas.

Le disque et les magasins montrent ce qui est installé, pas ce qui est servi

Lire un fichier PEM, un keystore Java ou le magasin machine de Windows renseigne sur ce qui est posé sur la machine. Pas sur ce que le service présente au réseau.

Côté PEM, openssl x509 -in fullchain.pem -noout -subject -dates -serial suffit. Pour les deux autres, honnêteté d'abord : nous n'avons pas pu exécuter les commandes correspondantes. Notre poste de test n'a pas de JDK et ne tourne pas sous Windows. Plutôt qu'une sortie inventée, voici la trace de la tentative :

$ keytool -list -v -keystore /Library/Keychains/System.keychain
The operation couldn't be completed. Unable to locate a Java Runtime.

$ file /usr/bin/keytool
/usr/bin/keytool: Mach-O universal binary with 2 architectures

$ pwsh -NoProfile -Command 'Get-ChildItem Cert:\LocalMachine\My'
Get-ChildItem: Cannot find drive. A drive with the name 'Cert' does not exist.

Ces deux échecs démontent chacun un faux positif de disponibilité. La machine expose bien un binaire /usr/bin/keytool, mais c'est un binaire de substitution Apple qui redirige vers le site de Java : which keytool qui répond ne prouve rien sur macOS. Et installer PowerShell 7 sur macOS ou Linux ne donne aucun accès au magasin de certificats, le fournisseur Certificate étant une brique Windows absente de la liste des PSProvider. Ce script ne se valide que sur sa cible.

Les pièges comptent autant que les commandes. keytool demande son mot de passe de façon interactive, et le passer avec -storepass l'expose dans l'historique et dans ps : préférer -storepass:file. Depuis le JDK 9, le format par défaut est PKCS12, pas JKS. Côté Windows, LocalMachine\My exige une console ouverte en mode administrateur, faute de quoi la liste revient tronquée sans message d'erreur, et un binding IIS peut pointer une empreinte différente de ce qui est installé.

Le scan réseau ne verra jamais vos serveurs de messagerie

Un scan réseau lit ce qui est réellement servi, ce qui en fait la source la plus fiable. Depuis un poste ordinaire ou depuis la plupart des clouds, il ne verra jamais vos serveurs de messagerie : le port 25 sortant y est filtré.

La preuve tient en trois lignes, sur un seul hôte. smtp.gmail.com résolvait, au moment du test, vers une adresse unique, et les frontaux Google tournent : quelle que soit l'adresse rendue par la résolution, les trois ports donnent le même contraste. Le port 587 en STARTTLS et le port 465 en TLS implicite acceptent la connexion et rendent le certificat ; sur le port 25, la connexion expire. La machine est joignable, c'est le port qui est bloqué. Rejouée vers sept MX publics de six opérateurs différents, deux chez Google, puis Proton, OVH, Riseup, Yandex et GMX, la même commande expire sept fois sur sept.

Le port 25 est filtré chez nous, en sortie. La nuance compte, parce que la conclusion inverse traîne partout. Google ne ferme rien. AWS, GCP, Azure et OVH bloquent le 25 sortant par défaut, tout comme la quasi-totalité des accès résidentiels. Un scan de parc lancé depuis une machine de ce type produit donc un résultat mécaniquement incomplet.

Le même symptôme recouvre pourtant deux causes distinctes, et la seconde ne vient pas de votre réseau. Depuis le même poste, pop.gmail.com expire sur le port 110 quand pop.gmx.net y répond, et imap.gmx.net répond sur le 143, STARTTLS validé, comme sur le 993 ; le 995 passe partout. Les ports en clair ne sont donc pas filtrés en sortie, contrairement au 25 : ce sont les hôtes Google qui jettent ces paquets sans réponse, parce qu'ils ne servent ni POP3 ni IMAP en clair. Politique du fournisseur d'un côté, filtrage du réseau de l'autre : deux causes d'« injoignable », un seul symptôme. Avant de conclure qu'un port est filtré, testez un second opérateur.

Un scanner d'inventaire doit donc distinguer trois états, pas deux : certificat lu, certificat en défaut et hôte non atteint. Un « injoignable » compté comme un « rien à signaler » est le pire résultat possible, parce que le tableau de bord reste vert sur des services qui n'ont jamais été mesurés. Et l'enjeu n'est pas théorique sur les MX : si le certificat change avant que l'enregistrement TLSA correspondant ne soit publié, la RFC 7672 interdit la remise du message par ce serveur et impose à l'émetteur de basculer sur le MX suivant ou de différer la remise.

Nos propres outils tombent sous la même limite : le moniteur d'uptime de CaptainDNS n'accepte que les schémas HTTP et HTTPS. SMTP, IMAPS et LDAPS restent hors de son périmètre.

Les API des fournisseurs voient ce que les trois autres sources rattachent mal

Reste la quatrième source, la moins spectaculaire : les API des fournisseurs. AWS Certificate Manager, Cloudflare ou un CDN qui termine le TLS pour vous détiennent des certificats que rien d'autre ne rattache correctement à votre parc. Les journaux de transparence les voient sans dire qui les opère, le disque ne les contient pas, et le scan réseau les attribue à l'infrastructure du fournisseur plutôt qu'à votre service. L'API est le seul endroit où ces terminaisons managées existent avec leur date d'expiration et leur mode de renouvellement.

Son angle mort est symétrique : chaque API ne couvre que ce qui vit chez ce fournisseur, et suppose des droits de lecture que l'équipe qui inventorie n'a pas toujours. Trois fournisseurs, c'est trois interrogations, trois jeux d'identifiants et trois formats de réponse à réconcilier.

Un inventaire s'indexe sur un couple (hôte, port), pas sur un nom

Même nom, même adresse IP, deux certificats. ldap.google.com résout vers une adresse IPv4 unique, 216.239.32.58. Un client par défaut y lit le numéro de série 84D4296C sur le port 389 en STARTTLS, et E97CCECB sur le port 636 en TLS implicite. Trois exécutions identiques, trois fois le même résultat.

Premier piège, le SNI. Sans lui, les deux ports renvoient la sentinelle de Google, CN=invalid2.invalid avec OU=No SNI provided - please fix your client., numéro B3E9BADC : un scanner sans SNI enregistre une valeur parfaitement stable et parfaitement fausse, toujours sans erreur.

Le port lui-même n'est pourtant pas la cause de l'écart entre 389 et 636. L'écouteur du 389 détient les deux certificats et tranche selon les algorithmes de signature que le client annonce :

openssl s_client -starttls ldap -connect ldap.google.com:389 -servername ldap.google.com \
  -sigalgs 'RSA-PSS+SHA256:rsa_pkcs1_sha256' </dev/null 2>/dev/null | openssl x509 -noout -serial

serial=E97CCECBFFF70F940963C3B2C1F06634

Le 389 rend donc à la demande le certificat qu'on croyait propre au 636. L'inverse échoue : ECDSA+SHA256 forcé sur le 636 déclenche un tls alert handshake failure (alerte 40), sans aucun certificat. Le 636 n'a que le RSA, et c'est ce qui sauve l'indexation par couple (hôte, port). Mais la configuration TLS du scanner est une variable d'entrée au même titre que le port : deux scanners aux algorithmes de signature différents inventorient deux numéros de série différents sur le même couple, sans lever la moindre erreur. Figez et documentez la configuration TLS du scanner, sinon l'inventaire n'est pas reproductible d'une exécution à l'autre.

Ailleurs, le comportement s'inverse : chez Gmail, les ports 465 et 587 servent le même certificat, 6D09D839.... Rien de cela ne se devine, et un inventaire indexé sur le nom d'hôte compte faux dans les deux sens : il fusionne des certificats distincts ou duplique le même.

La grille d'audit à télécharger en fin d'article reprend ces colonnes : une ligne par couple (hôte, port), le mode TLS, l'état du dernier scan avec ses trois valeurs possibles, la méthode de dépôt, celle de rechargement, le propriétaire nommé et la classe d'automatisation. Trois lignes d'exemple montrent le remplissage attendu, le reste est vierge.

Déléguer _acme-challenge sans donner les clés de la zone

Déléguer _acme-challenge par CNAME donne au client ACME un droit d'écriture sur une zone de validation dédiée, et rien d'autre. Votre zone de production, elle, ne bouge pas : mêmes enregistrements, même API fermée.

Ce que la délégation CNAME est, et ce qu'elle n'est pas

La RFC 8555 ne mentionne pas le CNAME. Le mot n'apparaît nulle part dans son texte, vérification faite. La délégation n'est donc pas une recommandation du standard ACME : elle est documentée et supportée par Let's Encrypt, dont la validation DNS-01 suit les règles DNS ordinaires et accepte qu'un CNAME ou une délégation NS renvoie la réponse au défi vers une autre zone. Côté réglementaire, les Baseline Requirements citent explicitement l'enregistrement CNAME parmi les supports valides de la méthode de validation « DNS Change », à la section 3.2.2.4.7.

La distinction tient en une ligne : supportée par l'écosystème, absente du standard.

Le bénéfice, lui, est net. Le client ACME reçoit des identifiants qui n'écrivent que dans une zone de validation, souvent hébergée ailleurs. La compromission du serveur qui renouvelle ne donne alors aucun pouvoir sur vos enregistrements MX, A ou TXT de production. En balayant 32 domaines publics, nous avons trouvé plusieurs délégations réelles de ce type : fastmail.com renvoie vers fastmail.com.acme-challenge.fmhosted.com, github.com vers github.com.acme.github.net, reddit.com vers une cible dcv.cloudflare.com, eff.org et digitalocean.com vers fastly-validations.com.

Vérifier une délégation : trois étapes, jamais une seule

Une seule requête ne prouve rien. La vérification complète en demande trois, et la troisième est celle qui transforme un doute en preuve.

Étape 1, le CNAME existe :

dig +noall +answer _acme-challenge.fastmail.com CNAME

_acme-challenge.fastmail.com. 3600 IN CNAME fastmail.com.acme-challenge.fmhosted.com.

C'est tout ce que dit cette commande : un CNAME est écrit. Elle ne prouve pas que la délégation fonctionne.

Étape 2, suivre la chaîne jusqu'au TXT et lire le statut :

dig +noall +answer +comments _acme-challenge.fastmail.com TXT

Trois cas réels, et c'est ici que la plupart des articles se trompent :

CAS A - fastmail (CNAME présent, cible sans TXT actif)
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59352
_acme-challenge.fastmail.com. 3600 IN CNAME fastmail.com.acme-challenge.fmhosted.com.

CAS B - reddit (CNAME présent, cible existante)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8461
_acme-challenge.reddit.com. 292 IN CNAME reddit.com.7ee8918f112aca0f.dcv.cloudflare.com.

CAS C - captaindns.com (aucune délégation)
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27534
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

Il faut croiser deux signaux, jamais un seul. Un CNAME dans la section ANSWER avec un NXDOMAIN signifie que la délégation est écrite mais que la cible n'existe pas à cet instant, parce que le TXT n'est créé qu'au moment du challenge. C'est l'état normal entre deux renouvellements : sur les sept délégations publiques que nous avons interrogées, six étaient dans ce cas. Le vrai échec, c'est un NOERROR avec ANSWER: 0, autrement dit aucune délégation du tout. Un monitoring qui alerte sur le NXDOMAIN de _acme-challenge produira du bruit permanent, et se trompera six fois sur sept.

Étape 3, vérifier au niveau autoritaire et confirmer que la zone cible est vivante :

ns=$(dig +short NS fastmail.com | head -1)
dig +noall +answer +comments @"$ns" _acme-challenge.fastmail.com CNAME
dig +noall +answer +comments acme.github.net SOA

Le SOA de acme.github.net répond NOERROR alors que la requête TXT sur _acme-challenge.github.com renvoyait NXDOMAIN : la délégation est saine, seule la réponse au défi est absente faute de renouvellement en cours. Un SOA en NXDOMAIN ou en SERVFAIL sur la zone cible, à l'inverse, signale une délégation cassée pour de bon, typiquement un compte de validation supprimé ou un domaine expiré.

Le nom commence par un underscore, que certaines interfaces d'administration mangent ou préfixent en double : vérifiez le FQDN renvoyé dans la réponse DNS, pas l'affichage du panneau ; une requête CNAME sur l'outil DNS Lookup le montre sans ouvrir un terminal. Un CNAME sur _acme-challenge est incompatible avec tout autre enregistrement au même nom, si bien qu'un ancien TXT de validation qui traîne rend la zone invalide. Les TTL observés vont de 3600 à 120 secondes selon les domaines : après correction, un résolveur peut servir l'ancienne réponse, NXDOMAIN compris, pendant toute cette durée, et c'est la cause numéro un des échecs de validation juste après un changement. Le head -1 ne teste qu'un seul serveur autoritaire. Enfin, interroger la zone cible ne prouve pas que le client y a les droits d'écriture : seule une émission réelle le prouve.

La limite d'un seul délégataire par domaine, et le brouillon qui la lève

Le DNS n'autorise qu'un CNAME par nom. _acme-challenge.captaindns.com ne peut donc être délégué qu'à un seul client à la fois. Multi-CDN, multi-région, migration sans coupure, certificat de secours émis par une seconde autorité : ces quatre besoins tombent tous sur le même mur, et aucun contournement propre n'existe côté DNS.

Un brouillon en cours à l'IETF s'attaque au problème. Le draft-ietf-acme-dns-account-label-03, Active Internet-Draft du groupe de travail ACME, révision 03 du 15 mai 2026, en dernier appel de groupe de travail au moment de notre vérification, définit un challenge nommé dns-account-01. Le principe : préfixer le nom de validation par un condensé de l'URL du compte ACME, selon la construction "_" || base32(SHA-256(ACCOUNT_URL)[0:10]) || "._acme-challenge". Chaque compte obtient ainsi son propre nom de validation, et plusieurs clients peuvent valider en parallèle sur le même domaine.

C'est un brouillon, pas une norme. Il n'a pas de numéro de RFC, son contenu peut changer à la prochaine révision, et nous n'annonçons aucune disponibilité chez une autorité de certification. À suivre si votre architecture est multi-fournisseurs, à ne pas mettre dans un plan de déploiement.

Le renouvellement d'un certificat SSL ne s'arrête pas à l'émission : le rechargement est le vrai maillon faible

certbot renew écrit le nouveau certificat sur le disque. Il ne recharge ni nginx, ni postfix, ni haproxy. Entre le moment où l'émission réussit et celui où le service présente le nouveau certificat, il y a un rechargement, et c'est là que la chaîne casse le plus souvent, sans qu'aucun journal ne s'allume. La parade côté client s'appelle un deploy hook, et le guide de gestion du cycle de vie des certificats lui consacre sa phase 3 ; le contrôle qui suit vérifie, de l'extérieur, qu'il a réellement fonctionné.

Le contrôle post-renouvellement, et ses cinq faux positifs

Le seul contrôle qui compte compare le numéro de série lu sur le disque à celui réellement servi sur le réseau :

HOST=api.captaindns.com
FILE=/etc/letsencrypt/live/$HOST/fullchain.pem

disk=$(openssl x509 -in "$FILE" -noout -serial | cut -d= -f2)
served=$(openssl s_client -connect "$HOST:443" -servername "$HOST" </dev/null 2>/dev/null \
         | openssl x509 -noout -serial | cut -d= -f2)

echo "disque=$disk"
echo "servi =$served"
[ "$disk" = "$served" ] \
  && echo "OK: le certificat servi est bien celui du disque" \
  || echo "ALERTE: le service sert un ANCIEN certificat -> reload requis"

Les deux branches ont bien été exécutées, avec deux numéros de série distincts :

CAS 1 - concordance
disque=05DFD8366DC6A73780F3707BC7E13F91E0EC
servi =05DFD8366DC6A73780F3707BC7E13F91E0EC
OK: le certificat servi est bien celui du disque

CAS 2 - divergence
disque=05DFD8366DC6A73780F3707BC7E13F91E0EC
servi =05B499411D7820A6C0EC7A0626E1BA25CF67
ALERTE: le service sert un ANCIEN certificat -> reload requis

Ce contrôle a ses pièges, et le premier est bête. Le cut -d= -f2 n'est pas décoratif : openssl affiche serial=05DF... et la comparaison échoue sans lui. Comparez le numéro de série, jamais la date d'expiration : deux certificats renouvelés le même jour peuvent partager notAfter. Le fichier fullchain.pem contient plusieurs certificats et openssl x509 -in ne lit que le premier, si bien qu'un fichier ordonné à l'envers fait comparer l'intermédiaire et échouer le test en permanence. Derrière un répartiteur de charge qui termine le TLS, le certificat posé sur le disque de l'origine n'a aucun rapport avec ce qui est servi au public : le contrôle devient un faux positif permanent, et il faut le viser depuis l'extérieur du répartiteur. Enfin, pour identifier le fichier plutôt que l'émission, remplacez -serial par -fingerprint -sha256.

Ce contrôle n'a rien de spécifique au 443. Nous l'avons rejoué hors web : en TLS implicite sur le port 465, puis en STARTTLS sur le port 587, avec le même numéro de série 6D09D839... des deux côtés. Un parc de messagerie se contrôle exactement pareil, à l'option de connexion près.

L'empreinte SPKI SHA-256 offre un contrôle complémentaire, en amont. Elle est exposée à la fois par notre SSL Certificate Checker et par le CSR Parser, de quoi prouver qu'un CSR donné a bien produit le certificat servi. Le rapprochement est manuel : rien ne le fait automatiquement à votre place.

Tous vos frontaux servent-ils le même certificat ?

Une boucle sur les adresses IP du service répond à la question en quelques secondes :

HOST=debian.org
for ip in $(dig +short A "$HOST" | grep -E '^[0-9]'); do
  printf '%-16s ' "$ip"
  openssl s_client -connect "$ip:443" -servername "$HOST" </dev/null 2>/dev/null \
    | openssl x509 -noout -serial | cut -d= -f2
done

Sur debian.org, les quatre adresses renvoyées ont toutes rendu le même numéro de série, 057EB3AB.... Parc homogène de ce côté. Le cœur de l'astuce tient dans le -servername posé alors qu'on se connecte à une IP : sans lui, on récupère le certificat par défaut du frontal, pas celui du vhost visé. Le grep -E '^[0-9]' filtre les lignes de CNAME que dig +short intercale, comportement observé sur www.google.com à cause d'une réécriture du résolveur local.

La boucle ne couvre que l'IPv4 : ajoutez un passage sur dig +short AAAA avec -connect "[$ip]:443". L'autre limite est plus vicieuse. Derrière un anycast (une même adresse annoncée depuis plusieurs points du globe), ces quatre adresses appartiennent au même point de présence vu depuis votre poste : vous le testez quatre fois, pas les N autres répartis dans le monde.

Diagnostiquer un port mal identifié en une ligne d'erreur

Inutile de deviner le mode d'un port : openssl le dit dans son message d'erreur. Un wrong version number signifie qu'il manque -starttls : le serveur attend un dialogue en clair avant la négociation. À l'inverse, un Didn't find STARTTLS in server response, trying anyway... suivi d'un unexpected eof while reading signifie que le -starttls est de trop, sur un port déjà chiffré : openssl tente quand même, attend une bannière en clair d'un serveur qui n'attend que du TLS, et la connexion meurt sur un EOF.

La commande équivalente sur un MX en port 25 s'écrit ainsi :

openssl s_client -starttls smtp -connect gmail-smtp-in.l.google.com:25 \
  -servername gmail-smtp-in.l.google.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates -serial

Non validée depuis notre poste, port 25 sortant filtré ; syntaxe validée à l'identique sur le 587. Nous ne publions donc aucune sortie pour celle-ci. Trois pièges valent quand même d'être signalés : le 2>/dev/null avale l'erreur réelle et vous laisse avec un Could not find certificate from <stdin> quel que soit le problème, le </dev/null évite que la session reste ouverte, et le -servername doit porter le nom du MX, pas celui du domaine de messagerie.

DANE et TLSA : le seul cas où l'ordre des opérations est normatif

Le rechargement a un dernier étage, réservé aux MX qui publient des enregistrements TLSA. Là, l'ordre des opérations cesse d'être une bonne pratique pour devenir une obligation. La RFC 7671, section 8.1, décrit la rotation en quatre temps : publier l'enregistrement TLSA du futur certificat à côté de celui du certificat courant, attendre au moins deux TTL le temps que les caches se vident, déployer alors le nouveau certificat et vérifier qu'il fonctionne, puis retirer l'enregistrement devenu obsolète. Deux TTL, pas 48 heures : la RFC raisonne en TTL, et vos TTL ne sont pas les nôtres.

Pour SMTP, la RFC 7672 en fait une obligation formelle. En cas de désynchronisation, la remise est interdite via ce serveur, et l'émetteur bascule sur le MX suivant ou diffère la remise.

Le mode de panne est asymétrique, et c'est ce qui le rend redoutable. Côté opérateur fautif, aucune alerte : la connexion est avortée par le client, les émetteurs qui ne valident pas DANE continuent de livrer, la supervision reste au vert. La RFC 7672 emploie le mot « unwittingly » pour décrire ce domaine partenaire qui se retrouve mal configuré à son insu. Côté émetteur validant, ce n'est pas silencieux mais différé : les messages s'accumulent en file d'attente, avec des avis de retard puis d'éventuels rebonds à expiration. Le destinataire final, lui, ne reçoit ni le message ni la moindre notification.

Reste une condition que la section 8.1 pose sans la souligner : l'usage, le sélecteur et le type de correspondance doivent rester inchangés. Si vous modifiez l'un de ces trois paramètres, c'est la section 8.3 qui s'applique, et la règle s'inverse.

Les cas rebelles à ACME : ce qui ne se laisse pas automatiser

Une partie du parc résiste, et pas pour des raisons de protocole. ACME sait émettre pour presque tout. Ce qui coince, c'est l'installation, le rechargement, ou le niveau de validation demandé.

La PKI interne et les certificats de deux ans

Les autorités internes échappent au calendrier du CA/Browser Forum, donc rien ne les pousse à raccourcir ni à automatiser. L'instance de démonstration publique de FreeIPA le montre bien : au relevé du 21 juillet 2026, ipa.demo1.freeipa.org servait un certificat valable du 23 avril 2025 au 24 avril 2027, soit deux ans, sur une chaîne signée par une racine privée.

Vu depuis un poste extérieur, openssl retourne verify error:num=19 self-signed certificate in certificate chain. Ce code se confond souvent avec un autre : verify error:num=20 unable to get local issuer certificate. Ils ne décrivent pas la même situation. Le 19 signifie que le serveur envoie bien sa racine privée dans la chaîne, mais qu'elle est absente de votre magasin local. Le 20 signifie que l'intermédiaire n'est pas envoyé du tout et qu'openssl ne peut pas remonter la chaîne. Dans les deux cas, le diagnostic est le même : problème de magasin de confiance, pas problème de certificat. Le correctif aussi : -CAfile ca-interne.pem.

Des passerelles existent pour ramener ces parcs vers ACME. Aucune ne se déploie sans contrepartie, et il vaut mieux la connaître avant.

• acme2certifier, sous licence GPLv3, place une façade ACME devant Microsoft ADCS via MS-WCCE ou les Certificate Enrollment Web Services. La révocation n'y est pas prise en charge et la chaîne de l'autorité doit être chargée à la main. C'est un projet communautaire porté par un mainteneur, actif : version 0.44 le 18 juillet 2026.
• step-ca est un point de défaillance unique dans sa configuration par défaut, à cause de sa base embarquée Badger qui ne gère pas la concurrence. La documentation décrit un déploiement multi-instances, au prix d'une base MySQL ou PostgreSQL externe et de la gestion distante des provisionneurs.
• HashiCorp Vault expose un serveur ACME depuis la version 1.14.0, avec une durée de vie plafonnée à 90 jours. C'est un serveur, pas un client, et la nuance change tout dans une architecture.
• EJBCA Community Edition : Keyfactor l'écrit lui-même dans le README du dépôt officiel, « EJBCA Community Edition is not intended for production use. »

Les certificats qu'ACME ne peut pas délivrer

Le niveau de validation étendue ne s'obtient pas par ACME. Il suppose une vérification d'identité juridique (catégorie d'activité, juridiction d'enregistrement, numéro au registre du commerce) qu'aucun challenge automatisé ne produit.

Le cas se croise en production. Au même relevé, sur le port 465, posteo.de servait un certificat de validation étendue valable du 18 février 2026 au 24 février 2027, soit 371 jours. Et pourtant, aucune violation du plafond de 200 jours. Le certificat a été émis avant le 15 mars 2026, et la règle n'est pas rétroactive. Nous n'en tirons aucune conclusion sur les pratiques de renouvellement de cet opérateur.

Le champ se rétrécit encore. Les certificats de marque VMC et CMC, utilisés par BIMI, se décodent avec notre analyseur dédié mais ne sont pas des certificats TLS de serveur. Les certificats clients, notamment ceux qui portent une authentification mutuelle, suivent quant à eux une chaîne d'émission et une distribution qui n'ont rien à voir avec ACME.

Les endpoints qu'aucun script ne recharge

Voilà le vrai plafond de l'automatisation, et le seul chiffre qui compte pour décider d'un achat. Passez votre parc en revue et comptez ce qui suit.

Les boîtiers réseau administrables uniquement par interface web. Les répartiteurs de charge matériels, dont la mise à jour de certificat passe par un formulaire. Les imprimantes, les équipements industriels, les caméras et tout ce qui embarque un serveur HTTPS oublié depuis l'installation. Les keystores Java protégés par un mot de passe interactif, qui bloquent net toute exécution non surveillée. Les magasins Windows, où l'installation d'un certificat ne suffit pas puisqu'un binding IIS peut continuer de pointer une autre empreinte. Les terminaisons TLS managées chez un fournisseur qui n'expose aucune API.

Le point commun n'est pas l'émission : ACME sait émettre pour tous ces noms. C'est l'installation et le rechargement qui restent manuels. Un script peut obtenir le certificat en quelques secondes, puis attendre qu'un humain se connecte à une interface pour le poser. À 200 jours de validité, cet humain intervient deux fois par an et personne ne s'en plaint. À 47 jours, il intervient huit fois par an et par endpoint au strict minimum, en renouvelant à l'échéance, et onze à douze fois en renouvelant aux deux tiers comme recommandé. Le coût devient une ligne de budget.

Mesurez-le maintenant, pendant que la fréquence est encore basse : nombre d'endpoints concernés, minutes réellement passées par rotation, propriétaire nommé. Ces trois colonnes valent tous les comparatifs d'outils.

Cadence, profils courts et ce qui borne réellement une boucle de renouvellement

Une boucle de renouvellement n'est pas bornée par la taille du parc. Elle est bornée par la cadence à laquelle chaque nom réémet, et par deux ou trois limites de taux qui n'ont rien d'intuitives.

Quand renouveler : la règle des deux tiers a une exception

La règle générale est simple : renouveler quand il reste un tiers de la durée de vie totale. Soit 30 jours avant l'échéance pour un certificat de 90 jours. Mais la documentation de Let's Encrypt prévoit une exception explicite pour les certificats valables moins de dix jours : pour ceux-là, le renouvellement est recommandé à mi-vie.

Le profil shortlived tombe pile dans l'exception. Il vaut 160 heures, soit 6,67 jours. Sa mi-vie est donc à 80 heures, ce qui donne 2,1 émissions par semaine et par nom.

Ce 2,1 est un modèle, pas une valeur publiée par Let's Encrypt. Ses cinq hypothèses, en clair. La validité de 160 heures est documentée. La semaine ramenée à 168 heures fixes est une approximation : le mécanisme réel est un seau à jetons à recharge continue. Le renouvellement à une fraction fixe et déterministe, sans gigue ni nouvelle tentative, est une hypothèse de modélisation. Un certificat égale un nom, alors que shortlived accepte jusqu'à 25 noms : regrouper divise le nombre de certificats d'autant. Et le calcul suppose zéro échec.

Réserve la plus importante : avec ARI, qui est le mode nominal, la cadence ne suit pas une fraction fixe mais la fenêtre suggérée par le serveur, dont ni la position ni la largeur ne sont publiées. Toute cadence en fraction de durée de vie décrit donc un filet de sécurité, pas le régime normal.

Quant à la « trentaine de noms par domaine en profil court » qui circule, elle divise un quota que les renouvellements ne consomment pas par une cadence qui ne s'applique pas à ce profil : nous ne la reprenons pas.

Ce que Let's Encrypt appelle un renouvellement

Deux mécanismes, deux régimes d'exemption. Les confondre est l'erreur qui coûte le plus cher en exploitation.

Par ARI, la commande newOrder désigne explicitement le certificat qu'elle remplace. Trois conditions, en réalité : cette désignation, au moins un identifiant en commun avec le certificat sortant, et un sortant qui n'a pas déjà été remplacé une première fois. L'exemption est alors totale. Toutes les limites de taux sautent, sans exception, et le périmètre des SAN peut même changer, puisque l'identité du certificat sortant est portée par le champ dédié.

Par détection sur jeu exact, le régime est plus étroit. Le jeu d'identifiants doit être strictement identique, la casse et l'ordre étant sans effet (nuance que beaucoup d'articles inversent). L'exemption ne couvre alors que New Orders per Account et New Certificates per Registered Domain.

Le corollaire mérite d'être affiché au mur : agrandir un certificat SAN pour y ajouter un sous-domaine consomme le quota des 50 par domaine enregistré, alors que le renouvellement à l'identique n'en consomme aucun. Écrire « 50 certificats par semaine par domaine » sans cette précision revient à décrire un plafond de parc qui n'existe pas. Cette limite mesure un débit d'entrée de nouveaux noms.

Les limites qui mordent, par ordre de dangerosité

Cinq limites de taux sont à connaître, et elles ne se valent pas. Les voici de la plus dangereuse à la moins gênante.

La première est la seule qu'une boucle légitime peut épuiser toute seule : 5 échecs d'autorisation par identifiant, par compte et par heure, recharge d'un échec toutes les 12 minutes, aucun relèvement possible, et surtout une application aux renouvellements. La deuxième compte les échecs consécutifs et met l'identifiant en pause au bout de 1 152 échecs d'affilée. C'est un compteur de série, pas un débit, et il se recharge d'un jeton par identifiant et par jour : une journée à cinq échecs n'en consomme que quatre en net, et la pause ne survient qu'au bout de 288 jours ; à 120 échecs par jour, elle tombe au bout de 10 jours, et à un seul par jour, jamais. Ces valeurs ne sortent pas d'un calcul maison, la documentation Let's Encrypt publie le tableau. Ne fusionnez pas les deux limites.

Vient ensuite le vrai plafond d'une boucle sans ARI : 5 certificats par jeu exact d'identifiants tous les 7 jours, recharge d'un certificat toutes les 34 heures, aucun relèvement. Une cadence de 2,1 passe confortablement, et la marge absorbe les nouvelles tentatives. Plus bas dans le classement, 10 comptes par adresse IP toutes les 3 heures ne mord que si chaque nœud crée son propre compte au lieu d'en partager un. La dernière n'est même pas un quota, mais une contrainte de profil : shortlived plafonne à 25 noms par certificat, contre 100 en classic. Passer au profil court impose donc de redécouper les gros certificats SAN, et ces découpages sont des émissions nouvelles, pas des renouvellements.

Les limites de taux de Let's Encrypt qui concernent une boucle de renouvellement

Valeurs documentées sur la page officielle des rate limits, consultée le 21 juillet 2026. Ces exemptions et ces plafonds sont propres à Let's Encrypt et ne se généralisent pas aux autres autorités de certification.

5

Échecs d'autorisation par identifiant, par compte et par heure

Recharge d'un échec toutes les 12 minutes, aucun relèvement possible, applicable aux renouvellements.

5

Certificats par jeu exact d'identifiants tous les 7 jours

Recharge d'un certificat toutes les 34 heures, aucun relèvement possible.

50

Nouveaux certificats par domaine enregistré tous les 7 jours

Débit d'entrée de nouveaux noms, recharge d'un certificat toutes les 202 minutes. Les renouvellements en sont exemptés.

1152

Échecs consécutifs avant mise en pause de l'identifiant

Compteur de série remis à zéro dès qu'une validation aboutit, sortie via le portail en libre-service.

Le guide d'intégration de l'éditeur ajoute deux conseils d'exploitation : au-delà de 10 000 noms, renouveler par petits lots plutôt qu'en gros paquets, et étaler une fois pour toutes les dates de renouvellement. Le formulaire de relèvement de quota ne concerne que deux limites, demande quelques semaines de traitement et ne remet jamais un compteur à zéro : outil de planification, pas recours d'urgence.

Tout ce qui précède décrit la politique de Let's Encrypt, et rien d'autre. Chez AWS Certificate Manager, le chiffre structurant n'est pas un nombre de certificats mais un débit, FinalizeOrder plafonné à une requête par seconde, et ces quotas sont documentés dans le guide utilisateur.

Le vrai mode de panne : deux scénarios, et aucun n'est un quota

Les incidents de renouvellement que nous voyons ne ressemblent pas à un quota d'émission dépassé. Ils ressemblent à ces deux scénarios, qui partagent une caractéristique désagréable : ils s'aggravent tout seuls.

Scénario 1, la boucle d'échec. Un identifiant DNS expire, une délégation casse, le port 80 se ferme derrière un changement de règle réseau. Le client ACME retente, souvent de façon agressive parce que c'est le réglage par défaut de beaucoup de configurations. Au sixième échec dans l'heure sur le même identifiant, toute commande portant ce nom est refusée, et la recharge tombe à un échec toutes les 12 minutes. Un incident réparable en dix minutes se transforme en panne de plusieurs heures, non pas à cause du problème d'origine, mais à cause du comportement du client face au problème. Et le compteur d'échecs consécutifs monte pendant ce temps vers les 1 152 de la seconde limite. La parade tient en deux réglages : un backoff exponentiel côté client, et une alerte sur l'échec de validation plutôt que sur la seule approche de l'expiration.

Scénario 2, le renouvellement qui cesse d'en être un. Sans ARI, ajouter ou retirer un seul nom d'un certificat SAN lui fait perdre son statut de renouvellement et rebascule la commande sur le quota des nouveaux noms. Or beaucoup de parcs génèrent leurs jeux de SAN depuis un inventaire dynamique : contrôleur d'ingress Kubernetes, environnements éphémères, plateformes de prévisualisation. Plus aucune commande n'est un renouvellement, et un parc pourtant stable consomme le débit réservé aux nouveaux noms.

Ce qui rend ce second scénario réel, c'est l'état des clients au 21 juillet 2026. Certbot lit ARI mais n'envoie pas le champ replaces : son implémentation reste en lecture seule, donc toutes ses commandes reposent sur la détection par jeu exact. lego envoie replaces depuis la v4.16.0 mais, depuis la v5.1.0, ignore ARI si les SAN ont changé. cert-manager sait l'envoyer, derrière le feature gate ACMEUseARI, classé Alpha et désactivé par défaut, disponible depuis la v1.21.0 publiée le 8 juillet 2026. acme.sh l'envoie depuis la version 3.1.4, publiée le 17 juillet 2026, soit quatre jours avant que nous vérifiions ce point. La protection existe dans la norme depuis juin 2025. Elle n'est effective presque nulle part.

Surveillance de l'expiration des certificats SSL : deux choses à surveiller, pas une

La surveillance de l'expiration et celle de l'échec de renouvellement sont deux systèmes distincts. Le premier voit la conséquence, avec des semaines de retard. Le second voit la cause, le jour même. Un parc correctement outillé a les deux, et ils ne dépendent pas du même composant.

Des seuils qui ne survivent pas aux certificats courts

Un seuil d'alerte fixé à 30 jours devient absurde sur un certificat de 47 jours. Il se déclenche dès le 17e jour de vie du certificat, c'est-à-dire pendant plus de la moitié de son existence. L'alerte est permanente, donc invisible, donc inutile. Le seuil doit devenir relatif à la durée de vie : une fraction, pas une constante.

Autant appliquer cette exigence à nos propres outils. Le SSL Certificate Checker de CaptainDNS utilise un seuil « expire bientôt » figé à 30 jours, et les paliers d'alerte de la note de posture sont J-30, J-14, J-7, J-3 et J-1. Un seuil relatif du type max(15, durée de vie / 3) est prévu par la spécification interne, mais il n'est pas implémenté. Sur un parc en profil court, ces valeurs sont à recalculer vous-même.

Ce qui doit déclencher une alerte en plus de l'expiration

En plus de la date d'expiration, six signaux méritent une alerte. Le dernier de la liste est le plus utile de tous.

• Un changement de numéro de série signale un renouvellement effectif, donc une bonne nouvelle qu'il faut quand même voir passer.
• Un changement d'émetteur peut trahir une bascule d'autorité non prévue.
• Une chaîne devenue incomplète casse la validation chez une partie des clients seulement, ce qui la rend difficile à reproduire.
• Un nom d'hôte qui ne correspond plus arrive après une migration.
• Un protocole ou une clé devenus faibles indiquent une configuration qui a régressé.
• Et surtout, l'échec de validation ACME : le seul signal qui arrive assez tôt pour éviter la panne.

À l'inverse, deux réflexes ne produisent que du bruit. Ne jamais alerter sur un NXDOMAIN de _acme-challenge, pour la raison exposée plus haut. Et ne pas alerter sur un simple changement d'empreinte sans changement d'état visible, sous peine de récolter des faux positifs à chaque bascule de frontal.

Nos limites, dites franchement, parce qu'elles changent la façon dont il faut lire les paragraphes précédents. La note de posture est un opt-in payant par moniteur. Sa cadence par défaut est de 86 400 secondes, soit un passage par jour : parler de « surveillance continue » serait faux. Il n'y a aucune découverte de parc, aucune énumération via les journaux de transparence : vous surveillez ce que vous déclarez, une URL à la fois. Et il n'y a aucun STARTTLS, donc rien sur vos serveurs de messagerie.

À partir de quand faut-il payer un outil ?

Le seuil d'achat ne se compte pas en certificats. Il se compte en endpoints qu'aucun script ne sait recharger. Un parc de 800 certificats entièrement pilotés par un contrôleur d'ingress ne justifie aucune dépense ; un parc de 60 certificats dont 25 vivent sur des boîtiers à interface web la justifie tout de suite.

Classez votre parc en trois colonnes, puis comptez la troisième.

Classe	Ce que le script fait	Ce qui reste humain
Automatisable de bout en bout	Émission, installation, rechargement, vérification du numéro de série servi	Rien en régime nominal
Semi-automatisable	Émission et dépôt du fichier	Installation ou rechargement manuel, souvent une console
Non automatisable	Émission seule	Connexion à une interface web, import du fichier, redémarrage

Le point de bascule se lit sur la troisième ligne, multipliée par la fréquence à venir. Un endpoint non automatisable coûte, en régime 47 jours, huit interventions par an au strict minimum, celui d'un renouvellement à l'échéance, et onze à douze en renouvelant aux deux tiers comme recommandé ; le guide du cycle de vie en modélise un peu moins de huit avec une autre hypothèse de calendrier, sans que l'ordre de grandeur ne bouge. Contre deux aujourd'hui. Faites le produit avec vos minutes mesurées, pas estimées, et comparez au prix d'une licence : le calcul ne demande ni benchmark ni appel d'offres.

Le modèle de seuil fourni en fin d'article rend ces hypothèses modifiables une par une : nombre d'endpoints non rechargeables, cadence de rotation par palier de validité, minutes par rotation, coût horaire chargé et prix de référence. Chaque valeur pré-remplie y porte son statut, documentée, dérivée ou relevée à une date, de sorte que remplacer nos hypothèses par les vôtres prend une minute.

Justement, les prix. Sur AWS Marketplace, relevé du 21 juillet 2026, la fiche AppViewX AVX ONE CLM affiche deux paliers publics sur contrat d'un mois : 2 100 $ par mois pour 100 certificats serveur et 4 200 $ par mois pour 250 certificats serveur. Le même éditeur publie 5 000 $ et 9 100 $ par mois sur sa fiche PKIaaS, ce qui interdit de présenter les 2 100 $ comme « le » prix public de l'éditeur. La fiche Venafi Certificate Management Service ne comporte aucun prix et renvoie à une offre privée sur devis. La fiche DigiCert affiche un montant de 5 000 $ pour un contrat de douze mois, tout en précisant qu'elle est réservée aux achats sur offre privée. Ce relevé porte sur les fiches consultées ce jour-là, sur une seule place de marché, et sur la notion de prix publiquement souscriptible. Il ne dit rien des tarifs négociés, ni des éditeurs absents de ce relevé.

Un mot sur le marché, formulé en constat d'absence. Aucun Magic Quadrant consacré à la gestion du cycle de vie des certificats n'est référencé sur gartner.com : le cabinet traite le sujet par un « Buyers' Guide for PKI and Certificate Life Cycle Management » publié le 29 mai 2025 et par un espace d'avis utilisateurs Peer Insights. Quant aux chiffres qui circulent dans les argumentaires, ils sont attribuables et rien de plus : dans un communiqué du 2 juillet 2025, DigiCert indique que 45 % des répondants à son enquête « Trust Pulse » déclarent avoir subi une interruption de service liée à un incident de certificat, et que 31 % font état de pertes comprises entre 50 000 et 250 000 dollars. Le communiqué ne précise ni le nombre de répondants, ni leur profil, ni les pays couverts, ni la période de collecte, et nous n'avons trouvé aucun rapport détaillant cette méthodologie à cette date. Ce sont des déclarations de répondants à une enquête commanditée par un acteur de la catégorie, pas une mesure.

Retenez le geste, pas les chiffres : comptez la troisième colonne, multipliez par vos minutes, comparez.

🎯 Plan d'action : la séquence à dérouler

Huit actions, dans cet ordre. Les trois premières se font une fois ; les suivantes deviennent des réflexes d'exploitation.

1. Inventorier par couple (hôte, port), en croisant les journaux de transparence, le disque et les magasins, puis le scan réseau. Lancez ce scan depuis un réseau qui ne filtre pas les ports sortants, sinon vos serveurs de messagerie n'apparaîtront jamais.
2. Traiter « hôte non atteint » comme un échec de l'inventaire, avec une ligne explicite dans le rapport. Un injoignable silencieux compté comme un succès est ce qui rend un tableau de bord faux.
3. Déléguer _acme-challenge par CNAME, puis vérifier la délégation en trois étapes : le CNAME existe, la chaîne se résout, la zone cible répond en SOA. Et ne pas alerter sur les NXDOMAIN hors période de renouvellement.
4. Vérifier après chaque renouvellement que le numéro de série servi est celui du disque, y compris hors 443. C'est le contrôle qui attrape le rechargement oublié, et il coûte deux lignes de script.
5. Mettre un backoff exponentiel dans le client et alerter sur l'échec de validation. Sans ça, un incident de dix minutes se transforme en blocage horaire.
6. Vérifier que votre client envoie replaces, ou accepter de dépendre de la détection par jeu exact, ce qui revient à figer vos SAN.
7. Passer les seuils d'alerte d'une valeur fixe à une fraction de la durée de vie. Trente jours ne veulent rien dire sur un certificat de 47 jours.
8. Compter vos endpoints non rechargeables avant de comparer des outils. Ce nombre décide de l'achat ; le nombre de certificats, non.

Huit actions, deux fichiers à télécharger, et un seul chiffre à produire : le nombre d'endpoints que personne ne sait recharger. C'est lui qui décide de la suite, pas la taille du parc.

FAQ

Est-il possible de renouveler automatiquement un certificat SSL ?

Oui, et c'est le mode nominal avec ACME depuis des années. La vraie question porte sur la chaîne complète : émission, installation, rechargement du service et vérification. L'extension ARI permet en plus de suivre la fenêtre suggérée par l'autorité, mais son support côté client reste inégal au 21 juillet 2026. Certbot la lit sans envoyer le champ replaces, cert-manager la garde derrière un feature gate désactivé par défaut, acme.sh l'a câblée en version 3.1.4 le 17 juillet 2026.

Comment automatiser le renouvellement des certificats SSL ?

Trois briques suffisent. Un client ACME planifié, qui obtient le certificat. Une délégation _acme-challenge par CNAME vers une zone de validation dédiée, ce qui évite de confier les clés de votre zone de production au serveur qui renouvelle. Et un contrôle qui compare le numéro de série lu sur le disque à celui réellement servi sur le port concerné. La troisième brique est celle qu'on oublie, et c'est celle qui détecte le rechargement manquant.

Comment renouveler un certificat SSL ?

Un renouvellement n'est pas une prolongation : c'est une réémission complète, avec une nouvelle validation de contrôle du domaine si la fenêtre de réutilisation a expiré. Chez Let's Encrypt, une commande est reconnue comme un renouvellement de deux façons : elle désigne le certificat qu'elle remplace via ARI, ou elle porte exactement le même jeu d'identifiants que le certificat sortant. Dans les deux cas, elle échappe aux limites d'émission pour les nouveaux noms.

Comment vérifier qu'un renouvellement a réellement pris effet ?

Laissez le client ACME faire l'émission, puis vérifiez le résultat par le réseau plutôt que par les journaux du client. La commande utile compare openssl x509 -in fullchain.pem -noout -serial au numéro de série retourné par openssl s_client sur le service. Si les deux diffèrent, le certificat est renouvelé sur le disque mais le service sert encore l'ancien : il manque un rechargement.

Que faire si mon certificat SSL expire ?

Sur un service web, l'expiration se voit immédiatement : les navigateurs bloquent. Sur un serveur de messagerie protégé par DANE, c'est plus sournois. La RFC 7672 interdit la remise via un serveur dont l'authentification échoue, et l'émetteur bascule sur le MX suivant ou diffère la remise : de votre côté, aucune alerte. Commencez donc le diagnostic par une lecture du certificat réellement servi sur le port concerné, pas par vos journaux applicatifs.

Combien de certificats Let's Encrypt puis-je renouveler par semaine ?

La question part d'une idée fausse, la plus répandue du sujet. Les renouvellements sont exemptés de la limite des 50 certificats par domaine enregistré et par période de 7 jours : cette limite mesure l'entrée de nouveaux noms. Un renouvellement piloté par ARI échappe même à toutes les limites. Sans ARI, la seule contrainte qui mord est le plafond de 5 certificats par jeu exact d'identifiants tous les 7 jours.

Comment inventorier un parc de certificats ?

En croisant quatre sources, dont aucune n'est complète. Les journaux de transparence listent ce qui a été émis publiquement mais ignorent votre PKI interne. Le disque et les magasins (PEM, keystores Java, magasin Windows) listent ce qui est installé, pas ce qui est servi. Le scan réseau lit ce qui est effectivement présenté, mais rate tout ce que votre pare-feu sortant filtre, à commencer par le port 25. Les API de vos fournisseurs couvrent les terminaisons TLS managées. Indexez le résultat sur le couple (hôte, port).

Comment déléguer _acme-challenge par CNAME sans donner les clés de la zone ?

Créez un CNAME de _acme-challenge.captaindns.com vers un nom hébergé dans une zone de validation dédiée, puis donnez au client ACME des identifiants qui n'écrivent que dans cette zone. Vérifiez en trois étapes : le CNAME est présent, la résolution du TXT retourne un statut cohérent, la zone cible répond en SOA. Un NXDOMAIN hors période de renouvellement est normal. Le brouillon draft-ietf-acme-dns-account-label-03 prévoit de lever la limite d'un seul délégataire par domaine, mais ce n'est pas encore une norme.

À partir de combien d'endpoints faut-il acheter un outil ?

Il n'y a pas de seuil universel, et surtout pas de seuil exprimé en nombre de certificats. Comptez les endpoints qu'aucun script ne sait recharger, multipliez par le nombre de rotations annuelles à venir (huit au strict minimum en régime 47 jours, onze à douze en renouvelant aux deux tiers) et par les minutes passées sur chacun. Comparez le total au coût d'une licence : sur AWS Marketplace, au dernier relevé, la fiche AppViewX AVX ONE CLM affiche 2 100 $ par mois pour 100 certificats serveur. Écrivez les hypothèses de votre calcul, elles comptent autant que le résultat.

Télécharger les tableaux comparatifs

Les assistants peuvent exploiter les exports JSON ou CSV ci-dessous pour réutiliser les chiffres.

• Télécharger le modèle de seuil paramétrable (CSV)
• Télécharger le modèle de seuil paramétrable (JSON)

Télécharger la checklist de déploiement

Les assistants peuvent exploiter les exports JSON ou CSV ci-dessous pour réutiliser la checklist.

• Télécharger la grille d'audit de parc (CSV)
• Télécharger la grille d'audit de parc (JSON)

📖 Glossaire

• ARI (ACME Renewal Information) : extension d'ACME normalisée par la RFC 9773, de statut Proposed Standard. C'est une extension, pas une révision d'ACME : elle n'obsolète ni ne met à jour la RFC 8555.
• DCV (Domain Control Validation) : preuve que le demandeur contrôle le domaine. Sa réutilisation est plafonnée à 200 jours depuis mars 2026, 100 jours en 2027 et 10 jours en 2029 : c'est ce compteur, et non la validité, qui tombe à 10 jours.
• Jeu exact d'identifiants : ensemble strictement identique de noms couverts par un certificat. Chez Let's Encrypt, il sert à reconnaître un renouvellement sans ARI ; la casse et l'ordre n'ont aucun effet, mais l'ajout d'un seul nom fait perdre le statut de renouvellement.
• Domaine enregistré : la partie du domaine achetée auprès d'un bureau d'enregistrement, identifiée via la Public Suffix List. Tous les sous-domaines partagent le même quota. Let's Encrypt n'emploie jamais le terme « eTLD+1 ».
• Profil shortlived : profil d'émission Let's Encrypt à 160 heures de validité et 25 noms maximum, en disponibilité générale depuis le 15 janvier 2026. Il reste optionnel, et ses certificats contiennent encore aujourd'hui une URL de liste de révocation.
• Endpoint non rechargeable : point d'accès sur lequel un certificat s'émet automatiquement mais s'installe à la main, faute d'API ou d'accès non interactif. C'est l'unité de compte du seuil d'achat.

---

Un dernier contrôle avant de partir. Le geste qui traverse ce playbook, comparer le certificat réellement servi à celui qu'on croit avoir déployé, a un terrain où il ne tolère aucune approximation : si vos MX publient des enregistrements TLSA, la rotation se vérifie avant le déploiement, jamais après. Le DANE/TLSA Checker résout vos enregistrements, valide la chaîne DNSSEC et peut, en option, confronter le certificat présenté par le serveur SMTP à ce que votre DNS annonce.

---

📚 Guides certificats et DNS connexes

• Ballot SC-085v2 : les AC vérifient DNSSEC avant d'émettre : ce que les autorités contrôlent dans votre DNS avant chaque validation.
• DANE et TLSA : le guide complet : publier et faire tourner les enregistrements TLSA au rythme des renouvellements.
• HSTS et preload : le guide complet : pourquoi la marge de manœuvre est nulle quand un site en HSTS voit son certificat expirer.

Sources

1. Let's Encrypt : Rate Limits
2. Let's Encrypt : Certificate Profiles
3. Let's Encrypt : Integration Guide
4. CA/Browser Forum : Baseline Requirements for TLS Server Certificates
5. draft-ietf-acme-dns-account-label : ACME DNS Labeled With ACME Account ID Challenge