Comment s’adapter à la réduction du cycle de vie des certificats et à l’évolution de la PKI

Résumé exécutif : Les programmes racines des navigateurs réduisent la durée de vie des certificats TLS (Transport Layer Security) de 100 à 47 jours d’ici 2029, et la fenêtre de validation de domaine qui soutient leur émission diminue tout aussi rapidement. Ajoutez la cryptographie post-quantique à l’équation et la gestion des certificats cesse d’être une tâche trimestrielle pour devenir un processus continu. Les procédures manuelles de renouvellement ne survivront pas à ce changement. L’émission automatisée et surveillée, oui.

À retenir :

• La durée de vie des certificats TLS descend à 64 jours en 2027 et à 45 jours en février 2028, obligeant la plupart des organisations à passer de quatre renouvellements par an à près de 12 ou 13 par certificat.
• La reuse de l’autorisation de contrôle de domaine passe de 30 jours actuellement à seulement 7 heures, ce qui impose de ne pas supposer que les validations précédentes restent valables.
• La migration vers la cryptographie post-quantique (PQC) vise des échéances de 2029 pour Google et de 2033 pour les systèmes de sécurité nationale américains, et cela impacte aussi les formats de certificats, pas seulement l’échange de clés.
• Les lacunes dans l’inventaire des certificats, en particulier pour les certificats privés, internes et externes, deviennent plus dangereuses à mesure que la durée de vie se raccourcit, car les certificats inconnus échouent plus vite.

La durée de vie des certificats TLS qui protègent vos sites web, API, services internes et intégrations tierces va considérablement se réduire, et la fréquence de renouvellement va augmenter d’autant.

Les programmes racines des navigateurs raccourcissent la période pendant laquelle un certificat est reconnu comme fiable après son émission. Matthew McPherrin, responsable technique de l’équipe SRE de Let's Encrypt, a présenté cette évolution lors d’un webinaire Red Sift animé par Billy McDiarmid, VP Customer Engineering. Sa conclusion est claire : le secteur se dirige vers des certificats valables en semaines plutôt qu’en mois.

Le calendrier publié est le suivant :

• Février 2027 : certificats de 64 jours
• Février 2028 : certificats de 45 jours
• Mars 2029 : limite globale de 47 jours pour le secteur, selon la résolution SC-081v3 du CA/Browser Forum

La plupart des organisations utilisent aujourd'hui des certificats de 90 jours renouvelés environ quatre fois par an. Avec un délai ramené à 47 jours, il faudra prévoir 12 à 13 cycles de renouvellement par an pour chaque certificat. Doubler le nombre de renouvellements revient à doubler les risques qu’un échec ne passe inaperçu, avec une fenêtre de réaction beaucoup plus courte avant qu’une panne survienne.

Des durées de validité plus courtes ressemblent à du travail opérationnel supplémentaire, et c’est effectivement le cas. Mais la logique de sécurité reste solide.

McPherrin cite deux avantages concrets. Un certificat compromis n’est utile à un attaquant que tant qu’il reste valide, donc une durée de vie plus courte réduit cette fenêtre, quel que soit le moment où la compromission est détectée. Révoquer devient aussi plus simple. Les listes de révocation (CRL) explosent lors des incidents, et des certificats courts impliquent moins de dépendance aux données de révocation durables.

La révocation elle-même reste souvent l’étape opérationnelle la plus complexe. Elle demande coordination entre équipes, information des clients et remplacements manuels. Réduire la durée limite aussi la période sur laquelle cette réponse doit s’étaler.

La validation du contrôle de domaine, preuve que vous possédez réellement un domaine avant que l’AC puisse émettre un certificat, voit aussi sa durée se raccourcir.

La plupart des autorités de certification permettent aujourd’hui de réutiliser une validation jusqu’à 30 jours. Ce délai passera à 10 jours, et à terme jusqu’à seulement 7 heures.

Si votre procédure d’émission dépend d’hypothèses à long terme, d’une validation manuelle, d’un identifiant que personne ne vérifie souvent, ou d’une tâche de renouvellement trimestrielle, c’est là que cela commencera à coincer. L’automatisation doit être capable de revalider seule dès l’expiration de la réutilisation. Il n’est plus question d’attendre que quelqu’un constate l’échec.

Le conseil le plus répété dans le secteur : automatisez l’émission et le renouvellement à l’aide de protocoles standards, pour remplacer les certificats sans intervention humaine.

L’automatisation peut parfois échouer. Les identifiants expirent, les APIs dysfonctionnent, les pipelines se bloquent. La solution n’est pas de vérifier un tableau Excel tous les trimestres. Il faut miser sur la supervision, la logique de réessai, et la visibilité totale sur le parcours de renouvellement, de l’émission jusqu’au rechargement du service.

Concrètement :

• Automatisez l’émission et le renouvellement via ACME (Automated Certificate Management Environment), le protocole pris en charge par la plupart des autorités de certification majeures.
• Surveillez en continu la réussite des renouvellements, et non uniquement les dates d’expiration.
• Testez toute la chaîne de bout en bout : émission, renouvellement, distribution et rechargement du service.
• Évitez les procédures dépendantes d’autorisation longue durée.
• Testez les profils à durée plus courte dans un environnement de test avant l’arrivée des échéances en production.

ACME réduit déjà l’enfermement auprès d’un fournisseur, car les grandes AC exploitent le même protocole et vos outils n’ont pas besoin de changer si vous changez de partenaire. Quelques évolutions méritent l’attention.

Les profils ACME permettent aux clients d’anticiper les durées de certificats plus courtes avant échéance obligatoire. Cela laisse aux grandes organisations le temps de tester la transition vers les 45 jours avant sa généralisation.

Renewal Info a pour but de rendre la révocation côté AC moins critique, donnant aux clients la possibilité d’apprendre automatiquement le chemin de remédiation adapté, au lieu de mobiliser quelqu’un en urgence pour comprendre la panne.

Les certificats à durée très courte, y compris l’option à six jours sur opt-in, rendent l’automatisation totalement indispensable. La recommandation de McPherrin est pragmatique : cela ne fonctionne que si votre supervision est déjà performante, car il n’y a plus de place pour une reprise manuelle lente.

De nouvelles méthodes de validation sont également en développement pour faciliter l’adoption de la validation de domaine basée sur le DNS dans des organisations dont l’infrastructure ne correspond pas aux défis actuels.

L’automatisation du renouvellement ne sert à rien si vous ne connaissez pas l’ensemble des certificats à gérer. Les efforts de visibilité s’arrêtent souvent aux certificats publics gérés par une ou deux équipes. La réalité, c’est bien plus :

• Certificats privés et internes
• Certificats dans des environnements IT non déclarés
• Certificats tiers intégrés dans les solutions SaaS et les intégrations externes
• Certificats sur des services décommissionnés qui n’ont pas été nettoyés
• Certificats liés à des CDN ou des plateformes tierces
• Dérive d’inventaire après une fusion ou acquisition

Un inventaire de certificats, c’est la liste exhaustive et à jour de chaque certificat utilisé dans votre écosystème, avec ses emplacements, la CA émettrice, la date d’expiration, et les systèmes qui le présentent ou lui font confiance. Plus la durée de vie diminue, plus les certificats inconnus échouent vite, et plus l’impact d’un renouvellement manqué s’aggrave.

La réduction de la durée est le défi immédiat. La cryptographie post-quantique (PQC) est celui du long terme, qui touche simultanément la confiance navigateur, les formats de certificats, les algorithmes de signature des AC, et les calendriers de compatibilité des appareils.

Les objectifs de migration varient selon les secteurs. Google vise 2029. Les systèmes de sécurité nationale américains visent 2030 et 2033. NIST et les programmes gouvernementaux alignés pilotent les standards.

La PQC n’est pas un simple interrupteur à basculer. Les signatures post-quantiques sont souvent bien plus volumineuses qu’aujourd’hui, ce qui implique plus de bande passante et des handshakes TLS plus lents en masse. Une proposition pour y remédier, les certificats Merkle Tree, regroupe les validations de signature et les distribue aux navigateurs en dehors de la séquence TLS, au lieu d’attacher une signature complète à chaque session. Cela ne rapporte que lorsque les navigateurs et clients les adoptent massivement.

La migration vers la PQC ne concerne pas que les certificats. L’échange de clés — la partie de TLS qui négocie un secret partagé pour la session — a autant d’importance à cause du modèle de menace « récoltez aujourd’hui, décryptez plus tard » : un attaquant capte le trafic chiffré aujourd’hui puis attend l’avènement du quantique pour le déchiffrer plus tard.

Le conseil de McPherrin ici est simple à appliquer par rapport au côté certificat : utilisez TLS 1.3, et activez l’échange de clés post-quantique hybride partout où l’infrastructure le permet. Le risque est moindre qu’une migration de certificat complète, la compatibilité ascendante étant meilleure et aucun changement de format de certificat n’étant requis.

Les dispositifs contraints ne s’intègrent pas directement dans le schéma standard de la PKI web. Autonomie, faible bande passante et possibilités de mise à jour limitées feront que les déploiements IoT s’appuieront sans doute sur une diversité d’algorithmes plus grande que celle de serveurs ou navigateurs. Certains supportent les approches basées sur Merkle Tree. D’autres auront besoin de formats de signature différents, avec des compromis propres de bande passante. Quelle que soit la stratégie pour votre web, vérifiez sa transposabilité sur la durée de vie des IoT avant toute généralisation.

Tenter de résoudre en même temps la réduction de la durée des certificats, l’automatisation ACME, les lacunes d’inventaire et la préparation PQC, c’est prendre le risque de coupures imprévues. Segmentez l’effort en étapes maîtrisables :

1. Testez les profils à durée réduite dans un environnement pilote.
2. Renforcez la supervision du renouvellement, le déploiement et le processus de rechargement.
3. Couvrez l’inventaire à 100 %, y compris internes et tiers — les plus souvent oubliés.
4. Activez TLS 1.3 et l’échange de clé post-quantique hybride partout où c’est possible.
5. Planifiez la transition PQC en fonction du calendrier réel de support par les navigateurs et appareils, non de la toute première date disponible.

La gestion des certificats passe d’un contrôle trimestriel à une surveillance continue. Comme le résume McPherrin, la PKI web aura de moins en moins de patience envers ceux qui continueront à gérer ça manuellement.

Connaître réellement ses certificats, automatiser leur renouvellement, et superviser l’ensemble du processus sont les clés pour détecter toute mauvaise configuration avant une panne.

Si vous suivez encore vos certificats dans un tableur, Certificate Essentials de Red Sift apporte une visibilité complète et une supervision en temps réel pour ne rien oublier. Il inclut l’inspection DNS, l’évaluation de posture TLS et un suivi dédié de la préparation PQC, avec la capacité d’accompagner les futures évolutions. Pour de l’aide concrète sur l’automatisation ACME, le guide de démarrage de Let's Encrypt est une bonne base pour commencer à tester.

Vous pouvez également revoir le webinaire complet à la demande pour accéder à l’intégralité des questions/réponses, dont la gestion des contraintes IoT et le fonctionnement des certificats post-quantiques avec ACME.