Certificats TLS de 47 jours en 2029 : ce que cela change vraiment pour vos pipelines CI/CD

Les maths : pourquoi 47 jours brisent le renouvellement piloté par les humains

Le CA/Browser Forum a ratifié SC-081v3 en avril 2025. Le ballot fait passer la validité maximale des certificats TLS/SSL publics de 398 jours à 47 jours selon un calendrier en quatre étapes : 200 jours à partir du 15 mars 2026, 100 jours à partir du 15 mars 2027 et 47 jours à partir du 15 mars 2029.

Les Subject Information — la fenêtre de réutilisation de validation de domaine — sont serrées en parallèle, de 398 jours aujourd'hui à 10 jours d'ici mars 2029. Ce deuxième chiffre est celui que la plupart des chefs de programme manquent lorsqu'ils mettent l'impact en tableur, et c'est celui qui casse chaque job de renouvellement existant qui batche la validation pendant la nuit.

Faites l'arithmétique sur un certificat. Un certificat de 47 jours renouvelé à la marque des 33 jours (deux semaines avant expiration, le tampon vers lequel convergent la plupart des post-mortems de panne) signifie un renouvellement tous les 33 jours. C'est environ 11 cycles de renouvellement par certificat par an, contre le cycle unique délivré aujourd'hui par un certificat de 398 jours.

Pour un parc de taille moyenne de 5 000 certificats publics — pas un hyperscaler, juste une entreprise régulée typique avec quelques centaines de hostnames publics, une flotte de passerelles API et une poignée de back-ends mobiles — cela représente 55 000 commandes ACME réussies par an, soit environ 150 par jour, chaque jour, y compris le samedi avant Noël. Un taux d'échec de 0,5 % représente désormais 275 certificats cassés par an, plus de cinq par semaine. À 1 % c'est une panne en production tous les jours ouvrés.

Le changement annoncé de 398 à 47 jours n'est pas une augmentation de 8,5x de la fréquence de renouvellement ; une fois que vous comptez les tampons et la réutilisation DCV, c'est plus proche de 11x.

Le tampon de 14 jours avant expiration mérite son propre paragraphe. Les SRE ne le choisissent pas arbitrairement — il absorbe le pire cas combinant un renouvellement échoué, un délai de pagination le week-end, un hoquet de propagation DNS et le temps qu'il faut à un ingénieur d'astreinte pour atteindre un ordinateur portable. Sur un certificat de 398 jours, 14 jours de tampon représentent 3,5 % de la durée de vie ; manquer le renouvellement au jour 384 et récupérer au jour 397 est sans incident.

Sur un certificat de 47 jours, 14 jours de tampon représentent 30 % de la durée de vie ; la première tentative de renouvellement doit réussir au jour 33, et un ingénieur d'astreinte qui remarque une commande bloquée au jour 41 a six jours, pas 60, pour la corriger. Tout ce qui était auparavant silencieusement absorbé par la longue traîne du certificat — un dépassement ponctuel de limite de débit ACME, un challenge DNS-01 qui ne s'est pas propagé, un load balancer qui n'a pas pris la nouvelle chaîne — va désormais alerter.

Vient ensuite le multiplicateur mTLS. Un seul endpoint TLS face utilisateur cache un éventail de connexions internes. Derrière un contrôleur d'ingress, vous pouvez avoir 40 microservices utilisant le TLS mutuel, chacun présentant un certificat client, chacun nécessitant que la CA émettrice, le bundle de confiance et la feuille restent synchronisés. Cilium, Istio, Linkerd et Consul Connect font tous tourner les certificats sidecar à granularité horaire ou quotidienne déjà, donc la couche service mesh va généralement bien.

La douleur est sur les choses qui ne sont pas dans le mesh : un cluster Kafka interne avec 18 brokers et 240 clients producteurs, un primaire Postgres avec 12 réplicas et 80 comptes de service applicatifs, un service gRPC fait maison qui code en dur un chemin JKS. Chacun devient une cible de renouvellement à la même cadence que le parc public, même s'il est invisible aux scanners web. La plupart des inventaires de certificats doublent lorsqu'on commence à compter les feuilles mTLS ; le calendrier de renouvellement triple.

Où votre pipeline dépend silencieusement de certificats à longue durée de vie

Si votre pipeline CI/CD traite encore les certificats comme une configuration statique, le calendrier de 47 jours fera apparaître chaque dépendance que vous avez oubliée. Commencez par Helm. Un chart Helm qui livre un `tls.crt` et `tls.key` sous `templates/secret.yaml` est un chart qui sera re-livré tous les 33 jours, pour toujours, juste pour pousser une feuille renouvelée. Soit vous découplez le secret du chart (la bonne réponse : cert-manager émet dans un Secret Kubernetes que le chart référence mais ne possède pas), soit vous acceptez que chaque montée de version de chart porte désormais une rotation d'identifiants. La même chose s'applique aux overlays Kustomize avec des PEM intégrés et aux certificats SSL cuits dans les ConfigMaps pour la rétrocompatibilité avec d'anciens sidecars.

Terraform est pire, parce qu'il rend le couplage invisible. Un schéma courant consiste à déclarer une ressource aws_acm_certificate aux côtés du load balancer qui la consomme. ACM avec validation DNS va bien. Le schéma qui casse est la ressource tls_self_signed_cert utilisée pour amorcer une CA interne, ou le aws_iam_server_certificate uploadé depuis un PEM stocké dans un module privé. L'un comme l'autre crée une dérive d'état à chaque cycle de renouvellement : Terraform voit le certificat changer hors bande et essaie soit de le rétablir, soit marque la ressource entière pour remplacement. À 47 jours c'est un apply forcé chaque mois sur des ressources qui devraient être stables.

Sortez le certificat de Terraform vers ACM, cert-manager ou votre plateforme de cycle de vie des certificats, et faites en sorte que Terraform y fasse référence par ARN.

Les AMI et les images de conteneurs sont les pires offenseurs, parce qu'elles encodent la durée de vie du certificat dans la durée de vie de l'artefact. Une AMI dorée construite trimestriellement avec un bundle CA cuit était acceptable lorsque les feuilles vivaient un an. Avec des feuilles de 47 jours et des changements de chaîne se propageant plus vite (les intermédiaires tournent aussi), une AMI construite au jour 1 d'un trimestre a un bundle obsolète au jour 14 et un intermédiaire manquant au jour 60.

Le bon mouvement est de ne rien cuire de crypto-spécifique dans l'image et de récupérer le trust store depuis un sidecar, un init container ou un timer systemd qui tire depuis une source managée. La même logique s'applique aux images Docker qui font COPY ca-certificates.crt au moment du build — tirez à l'exécution à la place, ou utilisez la fenêtre de mise à jour quotidienne du gestionnaire de paquets de l'OS.

Vient ensuite les empreintes héritées. Des coffres Ansible épinglant un certificat serveur par empreinte SHA-256. Des scripts de monitoring qui sondent openssl s_client -connect et grep pour un CN d'émetteur attendu. Des applis iOS avec NSPinnedDomains référençant un hash de clé publique. Des clients Java avec un override X509TrustManager codé en dur comparant les empreintes. Chaque empreinte est une bombe à retardement de 47 jours après mars 2029.

La mitigation est d'épingler la clé publique d'un intermédiaire ou la SPKI d'une clé de secours, et non la feuille — mais vous devez trouver chaque épinglage d'abord. git grep -r sha256- à travers le monorepo est un bon point de départ ; il renvoie généralement plus de résultats que l'équipe sécurité ne s'y attend.

Les dépendances qui mordent le plus dur sont celles que personne n'a documentées :

• Keystores Java (cacerts, keystore.jks) livrés avec un JAR et décompressés dans $JAVA_HOME/lib/security/ au moment du déploiement. JDK 21 supporte enfin le rechargement automatique du trust store ; JDK 8 et 11 non.
• Objets OpenSSL SSL_CTX chargés au démarrage du processus, jamais rechargés. Le reload de nginx gère ça ; HAProxy nécessite set ssl cert via l'API runtime ; beaucoup de services Go sur mesure conservent un seul *tls.Config pour la durée de vie du processus.
• Applis mobiles avec épinglage de certificat livrées via un app store. Le cycle de revue est de 24 à 72 heures et vous ne pouvez pas forcer les utilisateurs à mettre à jour. Une mise à jour d'épinglage de 47 jours doit être livrée au moins 30 jours avant la prochaine rotation, ce qui contraint votre calendrier de release.
• Firmware embarqué avec une racine codée en dur dans la flash. Si le fournisseur ne peut pas faire tourner, l'équipement devient une brique le jour où la racine expire.

ACME partout — quand c'est possible, quand ça ne l'est pas

Le protocole ACME standardisé dans la RFC 8555 est la seule réponse réaliste pour un renouvellement à haute fréquence. Il fonctionne en production aujourd'hui contre Let's Encrypt, Google Trust Services, ZeroSSL et la plupart des CA commerciales. La mécanique est bien documentée : une clé de compte, une commande, un challenge (HTTP-01, DNS-01 ou TLS-ALPN-01), un appel finalize et un téléchargement. Des implémentations comme cert-manager, acme.sh, lego, le CertMagic intégré de Caddy et le provider ACME de Traefik gèrent cela correctement.

Aucun d'eux ne casse sous la cadence de 47 jours ; les maths de limite de débit (Let's Encrypt autorise 300 nouvelles commandes par 3 heures par compte, 50 certificats dupliqués par semaine par FQDN) couvrent facilement une fréquence de renouvellement 11x pour tout parc réaliste, à condition que chaque certificat soit renouvelé à 33 jours, et non poursuivi au jour 46.

Là où ACME ne suffit plus, c'est aux frontières. La terminaison TLS publique sur un load balancer managé (AWS ALB, GCP HTTPS LB, Azure Application Gateway) est résolue — le fournisseur cloud gère ACME pour vous lorsque vous amenez le DNS dans sa zone, renvoyant un HTTP 202 sur soumission de commande et un 200 sur finalize.

Les services internes sur un service mesh sont résolus — cert-manager avec une CA interne (un moteur de secrets PKI Vault, une CA-as-a-Service ou votre CA d'entreprise exposant un endpoint ACME via quelque chose comme step-ca) émet des SVID à la demande. Le problème commence lorsque vous quittez la couche applicative.

Les équipements et appliances sont le cas dur canonique. Un cluster F5 BIG-IP de 2019, un Citrix NetScaler ADC de 2017, un pare-feu Palo Alto terminant l'inspection SSL, une flotte de WLC Cisco présentant des certificats de portail captif — presque tous parlent SCEP ou une API REST spécifique au fournisseur, pas ACME. F5 a ajouté le support ACME dans TMOS 17.5 (2024) pour les challenges HTTP-01 uniquement ; DNS-01 est toujours orchestré par le fournisseur. L'histoire ACME de NetScaler est arrivée avec la version 14.1 build 25 et seulement contre des CA nommées.

La plupart du support ACME des appliances est « la boîte peut récupérer son propre certificat depuis Let's Encrypt pour son interface de management », ce qui n'est pas le cas d'usage que les entreprises ont réellement — elles veulent qu'une ICA publique émette une chaîne vers l'appliance pour le trafic de production.

Le trou est comblé par un contrôleur qui exécute ACME au nom de l'appliance et pousse le matériel résultant via l'API native de l'appliance : iControl REST pour F5, NITRO pour Citrix, API XML PAN-OS pour Palo Alto. Construire ce contrôleur est un trimestre de travail ; l'acheter est un cycle de procurement.

Le middleware fourni par éditeur est l'autre catégorie. Les vieux SAP Web Dispatchers, les IBM Datapower XG45, les Oracle iPlanet Web Servers, tout ce qui possède un keystore Java manipulé via une GUI éditeur. La plupart n'ont pas de client ACME et n'en auront jamais.

Ils doivent être enveloppés par une automatisation externe qui fait la danse ACME, transforme le résultat dans le format de l'éditeur (PEM vers PKCS#12 avec un friendly-name spécifique, JKS avec un alias spécifique, un fichier PSE pour SAP), et le pousse via l'API que l'éditeur expose — ou, dans les pires cas, un hook de déploiement par SSH qui exécute la CLI de l'éditeur. C'est du travail d'intégration ingrat et c'est l'essentiel du programme.

Services internes : le problème de rotation que la plupart des équipes ignorent

Le TLS public obtient les gros titres ; le TLS interne est l'endroit où repose la dette opérationnelle. Une entreprise qui a 800 hostnames publics a probablement 20 000 endpoints TLS internes, la plupart en mTLS.

Le ballot CA/B Forum ne force pas la cadence interne à 47 jours — les règles s'appliquent uniquement aux certificats publics — mais la trajectoire est sans équivoque, et plusieurs cadres poussent déjà dans ce sens. NIST SP 800-52 Rev. 2 recommande des durées de vie courtes pour les certificats serveur. CNSA 2.0 attend des identités machine qu'elles tournent fréquemment. Le parc interne suivra le public, juste avec 12 à 18 mois de décalage.

Un service mesh gère sa propre rotation. Istio fait tourner les certs de workload toutes les 24 heures par défaut via SDS, avec une expiration dure à 90 jours. Linkerd est similaire. SPIFFE/SPIRE émet des SVID avec des durées de vie de 1 heure et renouvelle à 30 minutes. Si vos workloads vivent derrière un sidecar mesh, la discussion sur les 47 jours est sans objet pour eux — vous êtes déjà au-delà. Le problème est ce qui n'est pas derrière le mesh.

Kafka est la pire source unique de douleur de rotation dans la plupart des parcs. Un keystore de broker est un fichier JKS référencé par ssl.keystore.location dans server.properties. Le recharger nécessite soit un redémarrage du broker, soit, sur Kafka 2.5+ avec KIP-519, un appel alterConfigs contre une configuration en describe-uniquement. Même avec KIP-519, chaque producteur et consommateur client a son propre keystore et sa propre histoire de rechargement — la plupart des clients Java nécessitent un redémarrage de processus, ce qui signifie un cycle de redémarrage tournant de 33 jours à travers des centaines d'instances applicatives.

Postgres est similaire : SELECT pg_reload_conf() prend le nouveau contenu de ssl_cert_file, mais le client libpq met en cache le bundle jusqu'à la reconnexion.

RabbitMQ nécessite rabbitmqctl eval 'ssl:clear_pem_cache().' après rotation, sinon le nouveau certificat est ignoré jusqu'au redémarrage du processus.

Le TLS de base de données est l'endroit où le multiplicateur mTLS fait vraiment mal. Un cluster Postgres avec un primaire, deux standbys synchrones, quatre réplicas asynchrones, douze réplicas en lecture seule pour l'analytique, plus PgBouncer devant chacun, plus 200 comptes de service applicatifs présentant chacun un certificat client — c'est un cluster avec des centaines de certificats tournant sur le même cycle de 33 jours. La question d'orchestration n'est plus « comment je fais tourner » mais « dans quel ordre, avec quel chevauchement, avec quel rollback ».

Le bon schéma est l'acceptation double-cert : le serveur fait confiance à la fois aux anciennes et nouvelles chaînes pendant la durée de la fenêtre de rotation, les clients sont migrés un à la fois, et seulement après que chaque client a présenté le nouveau certificat, l'ancienne racine est retirée du trust store du serveur. C'est opérationnellement identique à un échange de chaîne TLS et c'est la seule chose que chaque propriétaire de services internes doit apprendre avant mars 2029.

Les passerelles API internes méritent une note. Un Kong, Tyk, Envoy front proxy, ou Spring Cloud Gateway assis entre workloads mesh et non-mesh est généralement à la fois client et serveur. Ses certificats amont (utilisés pour appeler les services internes) et ses certificats aval (présentés aux clients) tournent sur des calendriers différents pilotés par des équipes différentes. Coordonner cela sans système central de gestion automatisée des certificats signifie qu'au moins une équipe fera des échanges manuels toutes les deux semaines.

Observabilité : détecter les échecs de renouvellement avant qu'ils n'alertent

Vous ne pouvez pas corriger ce que vous ne pouvez pas voir. Le plus grand prédicteur unique des pannes de certificat sous un régime de 47 jours est de savoir si l'équipe a instrumenté le processus de renouvellement lui-même, pas seulement l'endpoint. La plupart des équipes ont une surveillance d'expiration TLS sur l'endpoint — une sonde Blackbox Exporter ou un check SSL Datadog qui alerte quand cert_age < 7 days. C'est nécessaire mais insuffisant. Au moment où le check d'endpoint alerte, le job de renouvellement échoue silencieusement depuis des semaines.

L'instrumentation qui compte vit une couche en dessous. Commencez par le résultat de la commande ACME — chaque commande doit émettre un événement structuré avec l'URL de la commande, le statut, la liste de FQDN, la méthode de validation et la durée de finalize. cert-manager expose cela comme certmanager_certificate_ready_status et les logs du contrôleur (cherchez Order failed avec statut 400 ou 429).

Au volume de commandes, la métrique sur laquelle alerter est le taux d'échec ACME par CA par heure, avec des seuils ajustés par CA : les limites de débit de Let's Encrypt renvoient HTTP 429 avec urn:ietf:params:acme:error:rateLimited, une CA interne tend à renvoyer 503 lorsque sa base de données est dégradée, et un déploiement DNS-01 mal configuré renvoie 400 avec incorrectResponse. La taxonomie d'erreur est dans la RFC 8555 section 6.7.

Construisez ensuite un histogramme d'âge de certificat à travers le parc. Exportez (now - notBefore) / (notAfter - notBefore) comme jauge par certificat. Un parc sain de 47 jours a une distribution centrée autour de 0,5 (renouvelée au point médian) avec une queue serrée. Une distribution bimodale — certains certs à 0,3, d'autres à 0,9 — signifie que l'automatisation échoue pour une cohorte et est rattrapée par un humain pour l'autre. Une longue queue au-delà de 0,95 est la population sur le point de tomber en panne. C'est le graphique le plus utile à mettre sur l'affichage mural de l'équipe plateforme ; il prédit les incidents trois semaines avant qu'ils ne se produisent.

La détection de mismatch de chaîne est le troisième pilier. Une feuille correctement renouvelée avec un intermédiaire obsolète est l'une des défaillances silencieuses les plus courantes. Les navigateurs la corrigent (ils utilisent le fetch AIA), mais les clients serveur-à-serveur avec des trust stores stricts échoueront avec UNKNOWN_CA ou unable to get local issuer certificate. Le check est mécanique : chaque scan d'endpoint doit enregistrer la chaîne complète servie, la comparer à la chaîne attendue pour cet émetteur, et alerter sur la divergence.

openssl s_client -connect host:443 -showcerts piped à travers un petit parser suffit ; les scanners commerciaux font cela nativement. Ajoutez une alerte pour toute feuille dont le champ caIssuers AIA pointe vers une URL renvoyant HTTP 404 ou 500 — cela signifie que la chaîne n'est pas reconstructible depuis les clients externes.

Le quatrième signal est le renewal lag : temps entre renouvellement planifié et déploiement réussi. Sous un régime de 47 jours, un renewal lag dépassant 4 jours pour plus de 5 % de la flotte est l'alerte précoce que la capacité opérationnelle est dépassée. Suivez-le comme un percentile (p95, p99) et rattachez-le à un runbook qui escalade quand p95 > 72 heures.

Construire une piste de transition de 2 ans : 2027 à 2029

L'erreur que les équipes feront est de traiter chaque étape calendaire comme un projet isolé : un sprint pour 200 jours en 2026, un sprint pour 100 jours en 2027, un sprint pour 47 jours en 2029. La bonne approche est de concevoir pour 47 jours dès le début et de traiter 200 et 100 comme des tests d'intégration. Le calendrier du CA/B Forum est en fait votre répétition générale gratuite : toute casse qui apparaît à 100 jours apparaîtra catastrophiquement à 47.

La piste se découpe en huit trimestres. T1 2027 — inventaire et analyse d'écart. Lancez une évaluation d'impact de la durée de vie plus courte des certificats contre chaque système. Cataloguez chaque endpoint, chaque format de keystore, chaque mécanisme de rechargement, chaque empreinte épinglée. Étiquetez chacun avec l'un des trois états : ACME-natif, ACME-contrôlable (API éditeur existe), manuel-uniquement. Le troisième bucket est votre backlog de migration.

T2 2027 — ACME pour TLS public, de bout en bout. À la fin du trimestre, 100 % des certificats face publique doivent être sur ACME avec au moins 1 renouvellement de 100 jours réussi observé en production. Construisez la stack d'observabilité en parallèle.

T3 2027 — détox CI/CD. Sortez chaque certificat des charts Helm, de l'état Terraform, des AMI et des images de conteneurs. Établissez le schéma de fetch à l'exécution comme la seule forme acceptable. Migrez toutes les CA internes pour exposer un endpoint ACME — step-ca, Vault PKI 1.11+, ou une offre commerciale.

T4 2027 — automatisation mTLS. Déplacez tous les workloads service-mesh vers la rotation basée sur SDS si pas déjà fait. Pour les workloads non-mesh, déployez des agents sidecar qui font tourner les keystores et déclenchent les rechargements. Critère d'acceptation : une durée de vie de cert forcée à 7 jours en staging tourne pendant deux semaines sans intervention manuelle.

T1 2028 — appliances et middleware. Construisez ou achetez les contrôleurs qui pilotent ACME contre F5, NetScaler, Palo Alto, SAP et similaires. C'est le trimestre le plus long et le plus dur ; budgétez de la contingence.

T2 2028 — élimination des empreintes et de l'épinglage. Auditez chaque épinglage (applis mobiles, firmware IoT, clients Java internes) et migrez vers SPKI-de-clé-de-secours ou supprimez. Les changements d'épinglage mobile doivent être livrés 60 jours avant la bascule.

T3 2028 — chaos et injection de défaillance. Lancez des exercices planifiés : tuez la clé de compte ACME, faites expirer un intermédiaire en staging, échouez DNS-01 pour un FQDN critique, étranglez la CA. Les modes de défaillance que vous n'exercez pas sont ceux qui vous alerteront en mars 2029.

T4 2028 — gel, dry-run à 47 jours. Réduisez volontairement les durées de vie des certs en production à 47 jours en novembre 2028, avant le mandat. C'est le seul test final crédible. Toute défaillance fait surface pendant que vous avez encore un tampon de quatre mois pour récupérer.

À travers la piste, trois pratiques de gouvernance doivent être actives d'ici T2 2027 : une politique écrite qui interdit les hypothèses de cert à longue durée de vie dans le nouveau code, un lint CI qui rejette les PR introduisant des certs cuits ou des empreintes codées en dur, et une revue trimestrielle de l'histogramme d'âge des certificats avec la direction de l'ingénierie. Sans elles, la piste est fiction.

Où s'inscrit Evertrust

Le calendrier de 47 jours est implacable d'une manière spécifique : il supprime le mou opérationnel qui a caché chaque maillon faible de la gestion de certificats pendant la dernière décennie. Renouvellements manuels, trust stores cuits, épinglage non documenté, appliances éditeur sans ACME, CA internes sans interface d'automatisation — tout cela a été porté par des durées de vie de 398 jours. Cela ne sera pas porté par des durées de vie de 47 jours. La correction n'est pas un outil unique ; c'est une discipline appliquée à travers découverte, émission, déploiement et observabilité.

Evertrust fournit la couche plateforme qui rend cette discipline opérable. La découverte continue fait apparaître chaque certificat public et interne, y compris les appliances qui se cachent en dehors de la PKI centrale. Une API d'émission unifiée parle ACME (RFC 8555), SCEP, EST et CMP, de sorte que le même workflow renouvelle un certificat ALB public, un broker Kafka interne et un serveur virtuel F5.

Les moteurs de politique imposent les contraintes d'algorithme, de durée de vie et de chaîne au moment de l'émission. L'orchestration de rotation gère les cas non triviaux — fenêtres d'acceptation double-cert pour les bases de données, rechargements JKS pour le middleware Java, redémarrages tournants pour les clusters Kafka.

L'observabilité est intégrée : taux d'échec ACME, histogrammes d'âge de certificat, détection de mismatch de chaîne et renewal lag sont des métriques de première classe, pas des add-ons.

Les équipes qui atteindront mars 2029 sans panne ne sont pas celles avec le plus d'ingénieurs. Ce sont celles qui ont commencé en 2026 avec un inventaire clair, une dorsale d'automatisation, et une stack d'observabilité qui fait remonter les défaillances trois semaines avant qu'elles n'alertent. Pour voir comment Evertrust accompagne chaque étape de la piste — de l'inventaire à l'émission ACME, à la rotation et à l'audit — explorez Evertrust Certificate Lifecycle Management.