Ce qu’il faut retenir
- Pour les certificats TLS publics émis depuis le 15 mars 2026 et avant le 15 mars 2027, les Baseline Requirements fixent un maximum absolu de 200 jours et recommandent de ne pas dépasser 199 jours.
- Le calendrier prévoit ensuite 100 jours au maximum à partir du 15 mars 2027, puis 47 jours à partir du 15 mars 2029. Renouveler manuellement n’est plus une stratégie durable.
- L’automatisation ne se résume pas à demander un certificat : elle couvre inventaire, validation de domaine, déploiement, rechargement, contrôle externe, alerte et révocation.
- Un certificat renouvelé mais jamais chargé par le service produit exactement la même panne qu’un certificat expiré.
200 jours n’est qu’une étape
Les exigences du CA/Browser Forum concernent les certificats serveurs TLS publiquement reconnus. La date d’émission détermine le plafond : 200 jours entre le 15 mars 2026 et le 14 mars 2027, 100 jours du 15 mars 2027 au 14 mars 2029, puis 47 jours à compter du 15 mars 2029. Les recommandations opérationnelles sont légèrement plus courtes — 199, 99 et 46 jours — afin d’éviter qu’une fraction de journée ne dépasse le maximum.
Cette réduction ne signifie pas qu’un certificat existant voit rétroactivement sa date de fin modifiée. Elle change la durée maximale des nouvelles émissions. Elle ne concerne pas non plus de la même manière une autorité de certification privée utilisée uniquement dans un réseau interne. Pourtant, la pratique interne mérite le même inventaire : une PKI privée oubliée peut interrompre un VPN, une API ou un service industriel sans qu’un navigateur soit impliqué.
Le calendrier rend visible une dette ancienne. Lorsque le cycle durait plus d’un an, une équipe pouvait survivre avec un tableur et des rappels. À 47 jours, la moindre absence ou erreur de saisie devient récurrente. Le chantier prioritaire est donc la chaîne automatisée, pas l’achat d’un nouveau tableau de bord.
Le premier risque est le certificat absent de la liste
Un inventaire utile part de l’extérieur et de l’intérieur. L’observation externe trouve les noms publics et les certificats effectivement servis. Les référentiels internes révèlent les terminaisons TLS derrière un répartiteur, les passerelles d’API, les équipements, les services de messagerie et les certificats clients. Les deux vues doivent être rapprochées.
Chaque entrée possède au minimum : nom de domaine ou usage, environnement, propriétaire technique, propriétaire métier, autorité émettrice, mécanisme de validation, lieu de stockage de la clé, point de terminaison, mode de déploiement, date d’expiration observée et procédure de révocation. Les alias et environnements éphémères sont inclus. La cartographie des intégrations et des API fournit souvent la meilleure entrée, car elle montre les connexions dont une expiration couperait un flux critique.
L’inventaire doit être réconcilié à fréquence définie. Un scan hebdomadaire des surfaces publiques, complété par une revue mensuelle des référentiels internes, constitue un point de départ ; la fréquence exacte dépend de la vitesse de création des services. L’indicateur important est le pourcentage de certificats observés sans propriétaire ou sans mécanisme automatique, pas le nombre brut de certificats.
ACME automatise l’émission, pas toute l’exploitation
Le protocole ACME standardise les échanges entre client et autorité de certification : création de compte, commande, preuve de contrôle d’un identifiant et récupération du certificat. Il permet de réduire les manipulations, à condition que le contrôle du domaine, les autorisations et le stockage des clés soient correctement conçus.
Une chaîne complète suit au moins huit étapes :
- détecter qu’un renouvellement doit commencer avec une marge suffisante ;
- créer ou renouveler la commande auprès de l’autorité ;
- réaliser le challenge sans exposer une permission DNS globale permanente ;
- générer ou sélectionner la clé selon la politique interne ;
- installer certificat et chaîne intermédiaire sur toutes les terminaisons ;
- recharger le service sans interrompre les connexions au-delà du seuil admis ;
- contrôler depuis l’extérieur le certificat réellement présenté, son nom et sa chaîne ;
- journaliser le résultat et alerter si la nouvelle expiration n’est pas observée.
Le compte ACME, le jeton DNS et la clé privée n’ont pas les mêmes fonctions. Ils reçoivent des droits séparés, une rotation et une journalisation. L’automatisation qui possède un accès complet à toute la zone DNS transforme un incident sur le renouvellement en incident de domaine.
Les équipes qui utilisent des agents ou des orchestrateurs doivent appliquer les mêmes limites que dans le dossier sur la cybersécurité des agents d’IA : capacité étroite, approbation pour les opérations sensibles et trace exploitable. Un assistant peut ouvrir un ticket ; il ne doit pas improviser une révocation ou modifier une zone critique sans politique explicite.
Le test utile commence lorsque quelque chose casse
Un renouvellement réussi en environnement nominal ne prouve pas la résilience. Le test doit couvrir un challenge DNS refusé, un quota ou une indisponibilité de l’autorité, un secret expiré, une chaîne intermédiaire incorrecte, un nœud oublié derrière le répartiteur, un rechargement échoué et un certificat qui ne contient pas tous les noms attendus.
Le scénario de référence suit une échéance artificiellement rapprochée en environnement de test. L’équipe mesure le moment où la demande commence, le délai de résolution, le déploiement sur chaque nœud et le contrôle externe. Elle vérifie que l’alerte contient le service, le propriétaire, l’expiration observée et l’action attendue. « Le certificat va expirer » sans cible ni procédure crée du bruit, pas une intervention.
Le retour arrière doit également être défini. Revenir au certificat précédent peut dépanner si celui-ci reste valide et si la clé n’est pas compromise. Ce n’est pas une réponse à une révocation. Chaque scénario précise donc le motif, l’autorité de décision et la preuve de fin d’incident.
Trois indicateurs suffisent pour commencer
Le premier indicateur est la couverture automatisée : part des certificats observés dont émission, déploiement et vérification sont automatisés. Le deuxième est la marge réelle : nombre de jours entre la fin du renouvellement vérifié et l’expiration précédente. Le troisième est le taux d’écart : certificats externes sans propriétaire, nœuds présentant encore l’ancienne version ou alertes sans résolution.
Le budget doit intégrer le temps d’ingénierie, l’observabilité, les secrets, les environnements de test et les exercices. Le raisonnement en coût complet du dossier sur le coût de l’infrastructure s’applique directement : un service d’émission peu coûteux peut reposer sur une chaîne d’exploitation fragile et chère à rattraper.
Enfin, les certificats sont une dépendance de tous les flux sécurisés, y compris ceux des agents et serveurs MCP. Ils doivent apparaître dans les revues d’architecture et les exercices de reprise. Le passage de 200 à 100 puis 47 jours ne crée pas cette exigence ; il retire simplement le délai qui permettait de l’ignorer.
Sources officielles
- CA/Browser Forum, Baseline Requirements for Publicly-Trusted TLS Server Certificates, version courante consultée le 30 septembre 2026.
- IETF, RFC 8555 — Automatic Certificate Management Environment, consultée le 30 septembre 2026.
La prochaine action raisonnable
Comparer cette semaine l’inventaire interne avec les certificats réellement présentés depuis l’extérieur. Toute terminaison sans propriétaire ou sans vérification post-déploiement devient un correctif prioritaire.
