Certificats TLS : la fin des renouvellements annuels impose l’automatisation

Un palier déjà franchi

Depuis le 15 mars 2026, un certificat TLS publiquement reconnu ne peut plus être émis pour plus de 200 jours. Jusqu’alors, la limite était de 398 jours, et beaucoup d’organisations vivaient au rythme d’un renouvellement annuel, déclenché par une alerte et traité à la main. Ce rythme ne tient plus : il faut désormais renouveler au moins deux fois par an, et le calendrier adopté par le CA/Browser Forum prévoit encore deux réductions, à 100 jours en mars 2027 puis à 47 jours en mars 2029.

Pour une banque ou une assurance, l’enjeu n’est pas cryptographique : il touche la disponibilité. Un certificat expiré interrompt un portail client, une API partenaire ou un flux interbancaire aussi sûrement qu’une panne de serveur, souvent sans signe avant-coureur lorsque personne ne savait qu’il existait.

Cet article fait le point sur le calendrier, son périmètre et ce que DORA exige déjà, puis sur les réponses : inventaire, automatisation par ACME, gouvernance, systèmes rétifs et crypto-agilité.

Ce que prévoit le scrutin SC-081v3

Le CA/Browser Forum réunit autorités de certification et éditeurs de navigateurs ; ses Baseline Requirements fixent les règles d’émission des certificats TLS publiquement reconnus. Proposé par Apple, le scrutin SC-081v3 a été adopté le 11 avril 2025 sans voix contre : 25 autorités pour, cinq abstentions, et l’accord d’Apple, Google, Microsoft et Mozilla. Il est entré dans les Baseline Requirements (version 2.1.5) avec effet au 16 mai 2025.

La section 6.3.2 fixe le calendrier : 398 jours pour un certificat émis avant le 15 mars 2026, 200 jours depuis cette date, 100 jours à compter du 15 mars 2027 et 47 jours à compter du 15 mars 2029. Elle recommande de rester un jour en deçà de chaque plafond (199, 99 puis 46 jours).

La section 4.2.1 réduit en parallèle la durée pendant laquelle une autorité peut réutiliser une validation déjà faite. Pour le contrôle des domaines et des adresses IP, elle est passée de 398 à 200 jours le 15 mars 2026, sera de 100 jours au 15 mars 2027, puis de 10 jours au 15 mars 2029. Pour les informations qui identifient le titulaire (Subject Identity Information), elle est passée de 825 à 398 jours le 15 mars 2026.

La justification est explicite : un certificat représente un état de fait à un instant donné, et plus il dure, plus il risque de rester valide alors que ses informations ne sont plus exactes. Le texte se réserve la possibilité d’ajuster le calendrier si nécessaire. Ce n’est pas une raison d’attendre : à la date de publication de cet article, il reste moins de cinq mois avant le palier de 100 jours.

Certificats publics, certificats internes : délimiter le périmètre

Les Baseline Requirements ne visent que les certificats TLS publiquement reconnus, émis par une autorité dont la racine est distribuée dans les logiciels courants. Le texte précise qu’il ne traite pas des certificats émis par une entreprise qui exploite sa propre infrastructure de gestion de clés (IGC) à des fins internes, et dont la racine n’est distribuée par aucun éditeur.

Les certificats de l’IGC interne d’une banque échappent donc aux 200, 100 puis 47 jours. Ils ne sont pas pour autant hors sujet : l’ANSSI recommande de fixer leur durée selon la sensibilité et l’exposition, en citant « quelques mois pour un certificat d’entité finale », et d’en automatiser le renouvellement.

Deux cas méritent une vérification dans la finance. Le TLS mutuel avec des partenaires, d’abord : la politique du programme de racines de Chrome indique que son magasin de confiance ne sert qu’à l’authentification de serveur TLS, et retire progressivement, depuis le 15 juin 2026, les hiérarchies qui ne sont pas dédiées à cet usage. Authentifier des partenaires avec des certificats publics suppose de vérifier la pérennité du montage auprès de son autorité. Les certificats qualifiés, ensuite : l’article 34 du règlement délégué (UE) 2018/389, pris pour la DSP2, impose aux prestataires de services de paiement de s’identifier par des certificats qualifiés de cachet électronique ou d’authentification de site internet. Ils relèvent de leur propre cadre, mais expirent aussi et doivent figurer dans l’inventaire.

Pourquoi le renouvellement manuel ne tient plus

À 200 jours, un certificat se renouvelle au moins deux fois par an ; à 100 jours, quatre fois ; à 47 jours, huit fois, et davantage en pratique, puisque l’ANSSI recommande de renouveler aux deux tiers de la durée de validité. Les auteurs de la RFC 8555 relevaient en 2019 qu’un administrateur mettait souvent une à trois heures pour obtenir et installer un certificat à la main. Sur un parc de plusieurs centaines de certificats, la charge devient intenable.

La réutilisation des validations pèse autant : à 10 jours, la preuve du contrôle d’un domaine devra être refaite presque à chaque émission. Les Baseline Requirements retirent en outre les méthodes de validation les plus manuelles : les dernières méthodes par téléphone sont exclues à partir du 15 mars 2027, celles par courrier électronique à partir du 15 mars 2028. L’approbation d’une demande par un clic dans un courriel est appelée à disparaître pour les certificats publics.

Le risque ne se limite pas aux échéances prévues. Une autorité doit révoquer un certificat sous 24 heures ou sous 5 jours selon les cas, notamment lorsque la validation du domaine n’est plus fiable ou que l’émission n’a pas respecté les règles. En juillet 2024, la CISA américaine a ainsi alerté sur la révocation d’une partie des certificats TLS de DigiCert, pour un défaut de conformité dans la vérification du contrôle de domaine, avec des perturbations possibles des services concernés. Un établissement qui remplace ses certificats en quelques heures absorbe ce type d’événement ; celui qui renouvelle à la main le subit. Comme pour les pannes massives des grands fournisseurs cloud, la question est celle d’une dépendance que l’on n’a pas cartographiée.

Ce que DORA exige déjà

Le règlement délégué (UE) 2024/1774, qui précise le cadre de gestion du risque lié aux TIC de DORA, consacre son article 7 à la gestion des clés cryptographiques. Son paragraphe 4 impose un registre à jour de tous les certificats et de leurs dispositifs de stockage, au moins pour les actifs de TIC qui soutiennent des fonctions critiques ou importantes. Son paragraphe 5 impose de veiller au renouvellement en temps utile des certificats avant leur expiration.

L’article 6 exige une politique de chiffrement et de contrôles cryptographiques qui prévoit la mise à jour de la technologie en fonction de l’évolution de la cryptanalyse. L’entité qui ne peut pas procéder à cette mise à jour adopte des mesures d’atténuation et de suivi, et en consigne la justification.

Un certificat expiré sur un service soutenant une fonction critique n’est donc plus un simple incident d’exploitation : il révèle un registre incomplet ou un processus défaillant, et entre le cas échéant dans la classification des incidents. La réduction des durées ne crée pas l’obligation ; elle la rend plus difficile à tenir sans outillage, et la rattache à la résilience opérationnelle de l’établissement.

Inventorier et découvrir avant d’automatiser

Automatiser un parc que l’on ne connaît pas ne traite qu’une partie du risque. Comme pour la gestion des vulnérabilités, la difficulté tient moins à l’outil qu’à la couverture.

Croiser les sources de découverte. Les registres publics Certificate Transparency, décrits par l’IETF dans la RFC 6962, permettent de surveiller l’apparition de nouveaux certificats publics pour ses domaines, y compris ceux commandés hors processus. Les balayages réseau révèlent les certificats réellement présentés par les services. Les consoles cloud, répartiteurs de charge, passerelles d’API, magasins de certificats et journaux de l’IGC interne complètent la vue.

Qualifier chaque certificat. L’inventaire utile indique l’autorité émettrice, publique ou interne, l’expiration, l’emplacement de la clé privée, les services consommateurs, la fonction métier soutenue et un responsable nommé. Sans responsable, une alerte d’expiration n’a pas de destinataire.

Relier les référentiels. Un certificat est une identité machine : il authentifie un service comme un mot de passe authentifie un utilisateur. Son inventaire gagne à être relié à la cartographie des actifs, au registre DORA et à la gestion des secrets.

Automatiser l’émission avec ACME

Le protocole ACME (Automatic Certificate Management Environment), publié par l’IETF en mars 2019 dans la RFC 8555, est le standard de l’automatisation. Un client installé près du serveur ouvre un compte auprès de l’autorité, prouve son contrôle du domaine en relevant un défi, puis reçoit le certificat. La RFC 8555 définit les défis HTTP-01 et DNS-01 ; la RFC 8737 a ajouté en 2020 le défi TLS-ALPN-01.

Le rattachement à un compte externe (External Account Binding, section 7.3.4 de la RFC 8555) associe un compte ACME à un compte client existant, pour encadrer qui demande quoi. L’extension ARI (RFC 9773, juin 2025) permet à l’autorité de suggérer une fenêtre de renouvellement, par exemple avant une révocation de masse.

Le guide de l’ANSSI Automatisation de la gestion des certificats avec ACME (collection « Les Fondamentaux », ANSSI-BP-106, version 1.1 du 10 septembre 2025) rappelle que l’automatisation limite le risque d’indisponibilité des applications métier. Il recommande notamment de renouveler aux deux tiers de la durée de validité, soit tous les 60 jours pour un certificat de 90 jours, de générer une nouvelle bi-clé à chaque renouvellement, de proscrire les certificats « wildcard », de réserver chaque certificat à un service TLS unique et de tester les processus en préproduction.

Pour l’IGC interne, les Essentiels de l’ANSSI consacrés aux infrastructures de gestion de clés (août 2025) recommandent d’« automatiser la génération, le déploiement et le renouvellement des certificats via la mise en oeuvre sécurisée de protocoles dédiés comme ACME ». Le guide sur ACME demande alors une autorité intermédiaire dédiée au service automatisé et recommande une validité d’au plus 90 jours pour les certificats qu’il émet.

Sécuriser la chaîne d’automatisation

L’ANSSI le souligne : l’automatisation apporte de nouveaux risques. Le client ACME détient des droits sur les serveurs web ou le DNS ; compromis, il peut obtenir des certificats pour tous les noms dont il sait faire valider le défi.

Limiter les privilèges. Le guide proscrit l’exécution du client avec les droits du super-utilisateur, pratique qu’il dit courante dans les documentations, au profit d’un compte de service dédié. Pour le défi DNS-01, il conseille de déléguer le sous-domaine _acme-challenge, par un CNAME vers un domaine tiers dédié ou par une délégation de zone, plutôt que d’ouvrir l’écriture sur la zone principale.

Cloisonner. L’ANSSI déconseille de concentrer tous les domaines sur un client et un compte uniques, dont la compromission toucherait l’ensemble du parc.

Restreindre qui peut émettre. Un enregistrement DNS CAA (RFC 8659) désigne les autorités autorisées pour un domaine. À partir du 15 mars 2027, les autorités devront traiter les paramètres accounturi et validationmethods de la RFC 8657, qui limitent l’émission à un compte et à des méthodes donnés.

Journaliser. Le client émettant sans contrôle humain, ses journaux doivent être centralisés et analysés pour vérifier qu’il ne sert que des noms légitimes. La surveillance de Certificate Transparency aide à repérer une émission inattendue.

Centraliser la gouvernance, superviser les expirations

Avec ACME, le certificat n’est plus remis à un responsable qui le transmet aux administrateurs : le client le reçoit directement. L’ANSSI note que cette délivrance décentralisée change le rôle des parties prenantes, et qualifie de « très importants » les changements techniques induits. La gouvernance doit donc rester centralisée : politique de certificats (autorités, durées, types de clés, nommage), référentiel unique, responsables désignés, coordination entre équipes réseau, DNS, systèmes, développement et sécurité. Dans une démarche ISO 27001, ce processus trouve sa place parmi ceux que le système de management documente et revoit.

La supervision reste indispensable dans un parc automatisé, car un renouvellement peut échouer sans bruit : défi bloqué par un filtrage, droits modifiés, limite de tentatives atteinte. Il faut contrôler le certificat effectivement présenté par le service, pas seulement la date inscrite à l’inventaire, avec des seuils adaptés : une alerte à trente jours n’a pas le même sens pour un certificat de 47 jours que pour un certificat d’un an. Ces alertes gagnent à remonter dans le SIEM. L’ANSSI recommande aussi de tester régulièrement les processus de renouvellement, y compris celui de l’autorité racine, à anticiper par exemple dès les deux tiers de sa durée de vie.

Les systèmes qui résistent à l’automatisation

Tout le parc ne se prête pas à ACME, et des exceptions demeureront. Certaines appliances ou équipements exposés n’acceptent qu’une installation par leur interface d’administration. Des environnements historiques, dont des mainframes, ne disposent pas toujours d’un client adapté. Lorsque la clé privée doit rester dans un HSM, l’outil doit savoir piloter la génération de la bi-clé dans le module.

Pour se protéger de l’interception, certaines applications mobiles épinglent la clé publique attendue du serveur ou de son autorité. La documentation Android recommande alors de toujours prévoir une clé de secours, faute de quoi un changement de clé ou d’autorité impose de publier une mise à jour pour rétablir la connexion. Avec une nouvelle bi-clé à chaque renouvellement, épingler la clé du certificat serveur devient intenable : la stratégie des applications mobiles et de leurs API doit être revue avant mars 2027.

Contourner quand c’est possible. Déplacer la terminaison TLS vers un répartiteur de charge ou une passerelle automatisés, déployer le certificat par l’interface programmatique de l’équipement lorsqu’elle existe, ou recourir à l’IGC interne pour les services qui n’ont pas besoin d’une reconnaissance publique.

Encadrer ce qui reste manuel. Exiger des fournisseurs le support d’ACME ou d’une API de déploiement dans les achats, et tenir un registre d’exceptions avec responsable, procédure testée et alertes renforcées : c’est la logique de mesures d’atténuation et de suivi du règlement délégué 2024/1774.

Crypto-agilité : un parc automatisé migre plus vite

L’ANSSI définit la crypto-agilité comme la capacité à étendre ou remplacer des composants cryptographiques sans affecter les fonctionnalités du système, en minimisant l’interruption de service. Sa note de janvier 2026 rappelle qu’il a fallu une dizaine d’années pour que les certificats SHA-1 deviennent rares, et que le Triple-DES reste partiellement utilisé dans l’écosystème bancaire. Un parc renouvelé automatiquement change d’algorithme au rythme de ses renouvellements ; un parc géré à la main, au rythme de ses projets.

La menace quantique vise les algorithmes à clé publique qui sous-tendent l’échange de clés et les signatures des certificats. Le NIST a publié en août 2024 ses premiers standards post-quantiques (FIPS 203, 204 et 205). L’ANSSI recommande l’hybridation pendant la transition et précise, dans sa fiche sur TLS 1.3 (février 2026), que l’hybridation de l’authentification suppose celle des certificats et des chaînes de certification, pour laquelle il n’existe pas encore de standard.

La feuille de route européenne coordonnée pour la transition post-quantique, publiée en juin 2025 par les États membres avec le soutien de la Commission, vise l’achèvement de la transition des cas d’usage à haut risque d’ici fin 2030, et des cas à risque moyen d’ici fin 2035. Elle souligne que la migration de systèmes complexes comme les IGC prendra du temps et recommande des inventaires cryptographiques. L’ANSSI juge pour sa part qu’il ne sera pas raisonnable d’acheter, après 2030, des produits sans cryptographie post-quantique. L’inventaire et l’automatisation des certificats sont la première brique de ce chantier.

Perspective Forum des Compétences

Le passage à 200 jours peut sembler un ajustement technique. C’est le premier palier d’un changement de méthode : avec 47 jours de validité et 10 jours de réutilisation des validations en 2029, la gestion manuelle des certificats publics ne sera plus une option. Pour les établissements financiers, le sujet est déjà réglementaire : le registre des certificats et leur renouvellement en temps utile figurent dans les normes techniques de DORA.

Trois actions se dégagent. Connaître son parc, par un inventaire qui croise plusieurs sources, distingue certificats publics et internes et rattache chaque certificat à un responsable. Automatiser par défaut, en suivant les recommandations de l’ANSSI pour que l’outil ne devienne pas une porte d’entrée. Traiter explicitement les exceptions, appliances, HSM ou applications mobiles, avec des mesures compensatoires documentées et des exigences portées dans les achats.

Le bénéfice dépasse la conformité : un parc inventorié et renouvelé automatiquement pourra aussi changer d’algorithme lorsque la migration post-quantique l’exigera.

La question à poser en comité des risques est simple : combien de certificats l’établissement devra-t-il renouveler chaque mois en 2029, et combien sait-il aujourd’hui renouveler sans intervention humaine ?

Sources publiques utilisées

Cet article s’appuie sur les textes et publications de référence suivants :

• CA/Browser Forum, scrutin SC-081v3 « Introduce Schedule of Reducing Validity and Data Reuse Periods », vote clos le 11 avril 2025, intégré aux Baseline Requirements (version 2.1.5) avec effet au 16 mai 2025.
• CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, version 2.3.1 du 4 octobre 2026, notamment sections 1.1, 1.2.2, 3.2.2.4, 4.2.1, 4.2.2.1, 4.9.1.1 et 6.3.2.
• IETF, RFC 8555 (ACME, mars 2019), RFC 8737 (défi TLS-ALPN-01, février 2020), RFC 9773 (ACME Renewal Information, juin 2025), RFC 8659 et RFC 8657 (enregistrement CAA, novembre 2019), RFC 6962 (Certificate Transparency, juin 2013).
• ANSSI, Automatisation de la gestion des certificats avec ACME (ANSSI-BP-106, version 1.1, 10 septembre 2025) ; Les Essentiels, Infrastructure de gestion de clés (IGC) (version 1.0, août 2025) ; ANSSI’s views on crypto-agility (janvier 2026) ; Transition post-quantique de TLS 1.3 (ANSSI-FT-115, février 2026) ; page consacrée à la cryptographie post-quantique.
• Règlement délégué (UE) 2024/1774 du 13 mars 2024 complétant DORA, articles 6 et 7 ; règlement délégué (UE) 2018/389 du 27 novembre 2017 (DSP2), article 34.
• Chrome Root Program Policy, version 1.8 ; documentation Android sur la configuration de la sécurité réseau (épinglage) ; CISA, alerte DigiCert Certificate Revocations du 30 juillet 2024.
• EU PQC Workstream, A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography (juin 2025) ; NIST, FIPS 203, 204 et 205 (août 2024).