Partie 5 · Défis du monde réel 9 min de lecture

Certificat plus court Durées de vie

Les jours des certificats TLS pluriannuels sont révolus. L'industrie se dirige rapidement vers des périodes de validité plus courtes, avec des certificats de 47 jours à l'horizon. Ce changement modifiera fondamentalement la façon dont les organisations gèrent leurs parc de certificats.

Faits rapides

Type
Éducatif
Niveau
Intermédiaire
Sujets
7 sections
Chapitre
22 sur 25
Suivant
Élaborer une stratégie CLM

Introduction

Pendant des années, les certificats TLS pouvaient être valides pendant trois, quatre ou même cinq ans. Les administrateurs demandaient un certificat, l'installaient et l'oubliaient largement jusqu'au prochain cycle de renouvellement. Cette époque touche à sa fin.

La trajectoire est indéniable : les périodes de validité des certificats se réduisent régulièrement, et le rythme s'accélère. En 2024, la validité maximale pour les certificats de confiance publique certificats TLS est de 398 jours (environ 13 mois). D'ici 2029, cette fenêtre se réduira à seulement 47 jours. Cela signifie que les organisations qui renouvlaient autrefois un certificat une fois par an devront bientôt le renouveler environ huit fois par an, par certificat.

Le changement n'est pas arbitraire. Il reflète un consensus croissant parmi les fournisseurs de navigateurs, les chercheurs en sécurité et les organismes de normalisation selon lequel des durées de vie plus courtes réduisent considérablement le risque. Mais pour les équipes informatiques qui dépendent encore de processus manuels ou de feuilles de calcul, les implications opérationnelles sont énormes.

Le Chronologie

L'histoire de la validité des certificats TLS est une histoire de compression progressive. Chaque réduction a été accueillie par une résistance de l'industrie, suivie d'une adaptation, puis d'appels à des périodes encore plus courtes.

1

Avant 2015: jusqu'à 5 ans

À l'époque des débuts du TLS commercial, les certificats pouvaient être achetés avec des périodes de validité de trois à cinq ans. Le renouvellement était peu fréquent, et la gestion des certificats était en grande partie un processus manuel et ad hoc géré par un petit nombre d'administrateurs.

2

2018 : le maximum de 2 ans

Le forum CA/Browser a voté pour limiter la validité des certificats TLS à 825 jours (environ deux ans). Ce fut la première réduction majeure et cela a indiqué la direction de l'industrie. Les organisations disposant de vastes parcelles de certificats ont commencé à ressentir la pression opérationnelle.

3

2020 : le maximum d’un an (398 jours)

Apple a annoncé unilatéralement que Safari rejetterait les certificats dont la durée de validité dépasse 398 jours. Google et Mozilla ont suivi le même mouvement. Le forum CA/Browser avait débattu de ce changement mais n'a pas pu parvenir à un consensus ; les fournisseurs de navigateurs ont imposé la décision. Cela est devenu la norme qui prévaut aujourd’hui.

4

2024 : la poussée de 90 jours

Google a publiquement préconisé une période de validité maximale de 90 jours, citant le succès de Let's Encrypt (qui délivre des certificats de 90 jours par défaut). La proposition a reçu un large soutien de la part des fournisseurs de navigateurs et des chercheurs en sécurité, préparant le terrain pour la prochaine réduction formelle.

5

2025 et au-delà : la route vers 47 jours

Le scrutin SC-081 d'Apple a été adopté par le forum CA/Browser, établissant une réduction progressive : 200 jours d'ici mars 2026, 100 jours d'ici mars 2027, et 47 jours d'ici mars 2029. La réutilisation de la validation de contrôle de domaine (DCV) sera également limitée à seulement 10 jours, ce qui signifie que l'ensemble du processus d'émission doit être automatisé de bout en bout.

Pourquoi l'industrie pousse à des durées plus courtes Durées de vie

La volonté de réduire les périodes de validité est motivée par des avantages concrets en matière de sécurité et d'opération. Comprendre ces motivations est essentiel pour communiquer l'urgence aux parties prenantes de votre organisation.

Fenêtre d'exposition réduite

Si une clé privée est compromise, les dommages sont limités à la durée de validité restante du certificat. Un certificat de 47 jours signifie qu'un attaquant peut exploiter une clé volée pendant des semaines, pas des mois ou des années. Des durées de vie plus courtes rendent la révocation moins critique, car les certificats expirent naturellement rapidement.

Atténuation de la compromission de la clé

Chaque cycle de renouvellement génère généralement une nouvelle paire de clés. Des renouvellements plus fréquents signifient que les clés sont tournées plus souvent, réduisant la fenêtre pendant laquelle une clé compromise reste utile. Cela s'aligne sur les principes de confiance zéro de la vérification continue.

Validation de domaine renforcée

Lorsque les données de validation de domaine peuvent être réutilisées pendant un an, les changements de propriété du domaine peuvent passer inaperçus. Des périodes de réutilisation de la DCV plus courtes (jusqu'à 10 jours) garantissent que chaque émission reflète l'état actuel du contrôle du domaine, empêchant la délivrance de certificats à des parties qui ne possèdent plus le domaine.

Agilité cryptographique

Lorsqu'un algorithme cryptographique est jugé faible, les certificats à courte durée de vie permettent à l'écosystème de passer plus rapidement. Au lieu d'attendre des années que les anciens certificats expirent, l'ensemble du parc peut être migré en quelques semaines. Cela est particulièrement pertinent alors que l'industrie se prépare à cryptographie post-quantique.

Le Forum CA/Navigateur Décision

Le CA/Browser Forum est l'organisme de l'industrie qui définit les règles régissant les certificats de confiance publics. Ses membres comprennent les autorités de certification (comme DigiCert, Sectigo et Let's Encrypt) et les fournisseurs de navigateurs (Apple, Google, Mozilla, Microsoft). Les décisions nécessitent un consensus des deux parties.

En 2024, Apple a soumis Ballot SC-081, proposant une réduction progressive de la durée maximale de validité des certificats TLS. Contrairement aux tentatives précédentes qui ont stagné en comité, ce scrutin a obtenu un large soutien. Les dispositions clés sont claires : la durée maximale de validité des certificats passe à 200 jours en mars 2026, 100 jours en mars 2027, et 47 jours en mars 2029. Tout aussi important, la période maximale de réutilisation du DCV diminue parallèlement, atteignant seulement 10 jours d’ici 2029.

Google avait proposé séparément de passer à des certificats de 90 jours, renforçant ainsi la direction. La convergence du scrutin d'Apple et du plaidoyer de Google a clairement montré que les durées de vie plus courtes ne sont pas une question de "si" mais de "quand". Les organisations qui attendent jusqu'en 2028 pour commencer à se préparer feront face à une transition douloureuse et précipitée.

Opérationnel Impact

Les avantages en matière de sécurité des durées de vie plus courtes sont réels, mais les défis opérationnels le sont également. Pour les organisations qui gèrent encore les certificats manuellement, l'impact sera sévère.

Explosion du volume de renouvellement

Une organisation disposant de 10 000 certificats renouvelés chaque année devra traiter environ 80 000 renouvellements par an dans le cadre d’un régime de 47 jours. Cela représente une multiplication par 8 du volume opérationnel. Sans automatisation, cette charge de travail est insoutenable.

L’automatisation devient obligatoire

Gestion manuelle des certificats (tableurs, rappels par courriel, flux de travail basés sur des tickets) ne peut tout simplement pas suivre le rythme des cycles de 47 jours. Gestion automatisée des certificats via des protocoles tels que ACME, EST et SCEP n’est plus un simple « nice‑to‑have » ; c’est une exigence pour la survie opérationnelle.

Risque accru de panne

Plus de cycles de renouvellement signifie plus d'opportunités pour que quelque chose tourne mal. Un renouvellement manqué, un déploiement échoué, un serveur mal configuré : chacun de ceux-ci conduit à pannes de certificats. La marge d'erreur se réduit à chaque diminution de la période de validité.

La visibilité devient cruciale

Vous ne pouvez pas automatiser ce que vous ne pouvez pas voir. Les organisations doivent d'abord atteindre une visibilité complète cycle de vie des certificats visibilité avant de pouvoir automatiser de manière fiable les renouvellements. La découverte et l'inventaire sont des prérequis, pas des options supplémentaires.

Préparer votre Organisation

La transition vers des durées de vie plus courtes ne se fait pas du jour au lendemain, mais la préparation doit commencer dès maintenant. Voici une feuille de route pratique pour anticiper le changement.

1

Inventorier tout

Commencez par une découverte complète de tous les certificats de votre infrastructure : serveurs, équilibreurs de charge, environnements cloud, CDN, appareils IoT et services internes. Vous devez savoir exactement combien de certificats vous gérez et où ils se trouvent.

2

Identifier les lacunes d'automatisation

Pour chaque certificat, déterminez si le processus de renouvellement et de déploiement peut être automatisé. Les certificats sur les systèmes hérités, les appliances sans prise en charge ACME, ou l'infrastructure gérée manuellement nécessiteront une attention particulière et éventuellement des intégrations personnalisées.

3

Déployer les protocoles d'automatisation

Implémenter ACME, EST, or SCEP à travers votre environnement. Priorisez les systèmes à haut volume en premier (serveurs web, équilibreurs de charge, clusters Kubernetes) et travaillez vers les cas limites. Testez les flux de renouvellement en profondeur avant que les échéances n'arrivent.

4

Raccourcir les durées de vie de manière proactive

N'attendez pas les mandats. Commencez à délivrer dès maintenant des certificats de 90 jours, chaque fois que possible, pour mettre à l'épreuve vos pipelines d'automatisation et vos flux de travail opérationnels. Les organisations qui ont déjà adopté des certificats à courte durée via Let's Encrypt ou des AC internes sont bien placées pour la suite.

5

Surveillance et alertes

Même avec l'automatisation, des choses échouent. Mettez en place une surveillance en temps réel de l'état des certificats, des taux de réussite des renouvellements et de la santé des déploiements. Configurez les alertes bien avant l'expiration afin que les défaillances soient détectées et résolues avant qu'elles ne provoquent pannes.

Comment nous aidons

Evertrust & Durées de vie plus courtes

Découverte complète du parc: Evertrust CLM scanne votre infrastructure entière en continu, identifiant chaque certificat quel que soit l'émetteur, l'emplacement ou le propriétaire. Vous obtenez une source unique de vérité avant de commencer l'automatisation.

Automatisation native au protocole: Evertrust PKI prend en charge ACME, EST, SCEP et CMP nativement, permettant une inscription, un renouvellement et un déploiement entièrement automatisés sans intervention manuelle. Que vous deviez renouveler tous les 90 jours ou tous les 47 jours, le processus est le même.

Alerte proactive: Politiques d'alerte configurables notifient les équipes appropriées au bon moment, que ce soit 30 jours, 14 jours ou 7 jours avant l'expiration. Les chemins d'escalade garantissent qu'aucun renouvellement ne passe inaperçu.

Tableaux de bord de préparation: Voir d'un coup d'œil quels certificats sont déjà automatisés, lesquels nécessitent encore une intervention manuelle, et où se trouvent vos lacunes. Suivez votre progression vers une préparation complète de 47 jours dans l'ensemble de l'organisation.