Automatiser et vérifier le renouvellement des certificats TLS

Séparer les trois échéances

Distinguez renouvellement du nom de domaine, échéance du certificat et validation de contrôle du domaine. Notez autorité, noms couverts, point où HTTPS se termine, responsable et procédure de renouvellement. Le CDN, le répartiteur et le serveur d’origine peuvent employer des certificats différents. Un abonnement d’hébergement renouvelé ne prouve pas que tous ces certificats le sont.

Pour les certificats TLS publics concernés par les Baseline Requirements, le maximum de validité passe à 200 jours pour les émissions du 15 mars 2026 au 14 mars 2027, puis 100 jours jusqu’au 14 mars 2029 et 47 jours à partir du 15 mars 2029. Ce sont des plafonds, pas des durées universelles. Le calendrier de chaque autorité peut être plus court.

Vérifier le profil utilisé, pas une durée supposée

Let’s Encrypt publie son propre calendrier : profil tlsserver à 45 jours depuis le 13 mai 2026 ; profil classique prévu à 64 jours le 10 février 2027, puis 45 jours le 16 février 2028. Vérifiez le profil réellement configuré et la documentation en vigueur avant de fixer une alerte. Ne présentez pas tous les certificats Let’s Encrypt comme déjà limités à 45 jours.

Choisissez une marge d’intervention adaptée au certificat observé et au délai réel de votre équipe. Une règle calée sur un ancien certificat annuel peut alerter trop tard. L’inventaire doit conserver début et fin de validité observés, sans contenir de secret. Une durée restante négative ou un nom absent est un défaut concret à traiter.

Tester émission et installation séparément

Le serveur de test de Let’s Encrypt permet de préparer l’intégration. Ses certificats ne sont pas destinés à être reconnus comme fiables par les navigateurs des visiteurs. Réalisez ce test dans un environnement prévu pour cela, puis contrôlez le parcours de production avec le certificat attendu.

Préparez un scénario où le fichier a été renouvelé mais où le service continue à présenter l’ancien certificat. Vérifiez le résultat depuis l’extérieur du point de terminaison, après rechargement ou déploiement. Pour plusieurs serveurs, contrôlez les différentes destinations. Conservez noms, date, certificat présenté et résultat de la connexion ; un journal « renouvellement réussi » seul ne couvre pas l’installation.

• Émission obtenue dans l’environnement de test.
• Installation et rechargement vérifiés.
• Certificat présenté au visiteur contrôlé.

Rendre la validation reproductible

Les défis ACME de Let’s Encrypt valident le contrôle du domaine : HTTP-01 emploie une ressource HTTP, DNS-01 un enregistrement TXT. DNS-01 permet notamment les noms wildcard. Identifiez les dépendances au DNS, au routage et au client ACME avant un changement d’hébergeur.

Une modification de redirection, une protection devant le serveur ou un changement DNS peut casser un mécanisme auparavant fonctionnel. Testez le chemin documenté après ces changements. La procédure nomme le propriétaire de la validation et son environnement, sans recopier les identifiants. Gardez un état de test lisible pour la personne qui reprend l’exploitation.

Surveiller le résultat et préparer la reprise

Le guide d’intégration de Let’s Encrypt recommande notamment un client capable d’exploiter les informations de renouvellement ACME lorsque disponibles. Documentez le mécanisme retenu, sa version, la dernière réussite et les erreurs. Ajoutez une observation indépendante du certificat réellement servi.

Décidez qui reçoit l’alerte, sous quel délai et comment escalader si personne ne répond. Une reprise doit expliquer diagnostic, installation et vérification après correction. Rattachez-la au plan d’incident et au carnet de recette. N’attendez pas la veille de l’expiration pour découvrir qu’une validation dépend d’une équipe indisponible.