Préparez-vous à la réduction de la validité des certificats

La validité maximale du certificat TLS public sera progressivement réduite :

• Jusqu'au 15 mars 2026, la validité maximale d'un certificat TLS est de 398 jours.
• À partir du 15 mars 2026, la validité maximale d'un certificat TLS sera de 200 jours.
• À partir du 15 mars 2027, la validité maximale d'un certificat TLS sera de 100 jours.
• À partir du 15 mars 2029, la validité maximale d'un certificat TLS sera de 47 jours.

La durée maximale pendant laquelle les informations de vérification du domaine et de l'adresse IP peuvent être réutilisées est également réduite :

• Jusqu'au 15 mars 2026, la durée maximale de réutilisation des informations de vérification est de 398 jours.
• À partir du 15 mars 2026, la durée maximale de réutilisation des informations de vérification sera de 200 jours.
• À partir du 15 mars 2027, la durée maximale de réutilisation des informations de vérification sera de 100 jours.
• À partir du 15 mars 2029, la durée maximale de réutilisation des informations de vérification sera de 10 jours.

La validité maximale du certificat détermine le nombre de jours pendant lesquels le certificat est considéré comme valide. Pour que l'autorité de certification (CA) puisse émettre un certificat, elle doit vérifier que le demandeur détient bien le contrôle du domaine ou de l'adresse IP indiquée dans le certificat.

Si aujourd'hui vous avez un certificat et que vous le renouvelez une fois par an (selon les règles actuelles), le contrôle du domaine est à nouveau vérifié à chaque renouvellement.

Mais que se passe-t-il si vous devez remplacer le certificat plus tôt qu'au moment du renouvellement – par exemple en cas de compromission de la clé privée ? Dans ce cas, la CA peut réutiliser la vérification effectuée lors du dernier renouvellement, vous évitant ainsi la nécessité d'une nouvelle validation. Cela est possible car la durée maximale de réutilisation de la vérification de domaine n'a pas encore expiré.

Les exigences de base (appelées exigences de base, c'est-à-dire les règles du CA/B Forum pour l'émission des certificats) ont toujours défini ces deux délais, mais ils étaient souvent définis à la même valeur.

Le changement dans la dernière phase des nouvelles règles – lorsque la validité maximale du certificat sera réduite à 47 jours, tandis que la vérification du domaine ne pourra être réutilisée que pendant 10 jours – vise à garantir que la vérification se déroule plus fréquemment. Le CA/B Forum suppose que les informations de contrôle de domaine deviennent rapidement obsolètes.

Le même calendrier de vérification de domaine s'appliquera également aux certificats OV et EV. Progressivement, il sera nécessaire de procéder à la vérification de domaine aux mêmes intervalles que pour les certificats DV, soit tous les 200 / 100 / 10 jours.

Les autres informations contenues dans les certificats OV et EV (comme le nom et l'adresse de l'organisation) ne nécessiteront toutefois qu'un renouvellement tous les 398 jours. Alors que la vérification de domaine peut et doit être automatisée, ces autres informations ne peuvent pas être entièrement automatisées.

Non, pas vraiment. La limitation concerne les certificats que les autorités de certification (CA) peuvent émettre, pas ceux que les navigateurs peuvent accepter.

Le navigateur vérifie uniquement si la date actuelle se situe dans la période de validité du certificat.

Une fois les changements dans les règles entrés en vigueur, les autorités de certification ne pourront plus émettre de certificats TLS avec une validité supérieure à 200 / 100 / 47 jours.

Un certificat avec une validité de 398 jours, émis avant l'entrée en vigueur du changement, restera valide jusqu'à son expiration. Il en va de même pour les certificats valides 200 jours au moment de la transition vers la limite de 100 jours, et pour les certificats valides 100 jours lors de la transition vers la limite de 47 jours.

Non, les exigences de base sont obligatoires uniquement pour les autorités de certification publiques.

Un PKI interne fonctionne à l'intérieur de votre réseau ou de vos clouds. Il inclut les autorités de certification, mais les politiques appliquées par les autorités de certification internes, y compris la durée de validité des certificats, sont définies par vous. Il peut être judicieux de choisir une courte durée de validité même pour un PKI interne, mais ce n'est pas obligatoire. Vous pouvez exploiter tous les logiciels pour le PKI interne vous-même, mais cela est complexe et sujet à erreurs. DigiCert propose plusieurs solutions PKI internes pour les scénarios d'entreprise, de cloud et de fabrication.

Non. Pendant la durée de la commande (en années), il n'y a pas de coûts supplémentaires pour le renouvellement ou le remplacement des certificats. Pendant la validité de la commande, vous pouvez effectuer un nombre illimité de nouvelles émissions.

Non, elles ne concernent que les certificats (leaf) finaux émis par l'autorité de certification intermédiaire. Il n’existe pas de règles du CA/B Forum ou d’autres organismes de normalisation qui limitent la durée de validité des certificats racines et intermédiaires, mais il existe de bonnes pratiques et les fournisseurs de logiciels utilisant des certificats fixent leurs propres règles pour leurs programmes de racines de confiance, qui peuvent varier considérablement.

La politique Mozilla Root Store (section 7.4) indique que Mozilla cessera de faire confiance aux certificats racines 15 ans après la génération de la clé.

Les règles de validité de la politique du programme de racines Chrome, version 1.6 (15 février 2025), sont plus complexes. Il n’y a pas de limite de validité fixe, mais « tout certificat racine CA avec un matériel clé correspondant à une clé générée il y a plus de 15 ans sera progressivement supprimé du Chrome Root Store ». Les racines contenant des clés créées avant le 16 avril 2014 seront supprimées selon un calendrier annuel défini dans la politique du programme de racines.

Le programme Microsoft Trusted Root indique que « les nouvelles autorités de certification racines (Root CA) émises doivent avoir une durée de validité minimale de huit ans et maximale de 25 ans à compter de la date de soumission ». La différence dans les règles entre la politique de Microsoft et les autres politiques provient de la diversité des applications que Microsoft prend en charge dans son PKI, qui est nettement plus large que celle des autres navigateurs.

Une des bonnes pratiques de bon sens est qu'un certificat racine CA ne doit pas expirer avant un certificat intermédiaire CA lié à celui-ci.

Une mauvaise gestion du cycle de vie des certificats racines et intermédiaires CA peut avoir des conséquences graves, comme l’a récemment démontré un certificat intermédiaire CA apparemment oublié de Google, qui a expiré et laissé de nombreux appareils Google Chromecast sans service.

Pour les cas courants et simples, tels que les serveurs Web et les certificats TLS publics, l'automatisation est gratuite pour les clients CertCentral grâce aux standards largement soutenus Automated Certificate Management Environment (ACME) et ACME Renewal Information (ARI).

Bien sûr, tous les certificats ne sont pas publics TLS et toutes les technologies ne supportent pas ACME. Pour ces cas, DigiCert Trust Lifecycle Manager propose des options avancées d'automatisation et d'intégration.

L'automatisation via ACME ne consiste cependant pas simplement à cocher une case. Certaines modifications doivent être effectuées sur le dispositif ou l'application (généralement un serveur Web) qui demande le certificat. Pour la plupart des administrateurs, ce processus est simple et bien documenté.

ACME est un environnement de gestion automatisée des certificats.
ARI est une information de renouvellement ACME.

ACME est une norme soutenue par toutes les grandes autorités de certification, au moyen de laquelle un logiciel client pour certificats (généralement un serveur Web) demande un certificat à l'autorité de certification et l'installe sur le client. (Dans ce scénario, le serveur Web est le client.)

Le logiciel client doit également prendre en charge ACME. Le support est répandu, mais pas universel. Le programme client ACME fonctionne généralement sur le système client selon un calendrier en utilisant Linux cron ou le planificateur de tâches sous Windows, mais il existe d'autres solutions qui intègrent la planification dans des produits plus importants.

ARI est une norme connexe qui permet à un serveur de recommander un calendrier pour que le client sache qu'il doit renouveler le certificat avant son expiration. Avec une configuration correcte, ARI peut ordonner au client de renouveler même si le certificat a été révoqué, évitant ainsi une interruption.

Conformément aux nouvelles règles des certificats TLS, à partir du 15 mars 2026, la vérification des informations d'identité du sujet (Subject Identity Information, SII) ne pourra être réutilisée que pendant 398 jours au lieu de 825 jours.

Cela signifie que l'impact principal sera la nécessité de vérifier à nouveau les informations d'identité du sujet (SII) — c'est-à-dire les informations dans le certificat qui identifient votre organisation — chaque année, au lieu de tous les deux ans.

Selon les exigences de base TLS, un appel téléphonique annuel avec un représentant de DigiCert est nécessaire, ce qui signifie que ce processus ne peut pas être entièrement automatisé.

Il convient de noter que les certificats OV et EV protègent également les noms de domaine, de sorte que leur durée de validité changera selon le même calendrier que pour les DV : 200 jours en 2026, 100 jours en 2027 et 47 jours en 2029. La nécessité d'automatiser la gestion de ces certificats est donc tout aussi cruciale que pour les certificats DV.

Le chiffre 47 jours peut sembler arbitraire, mais il est basé sur une simple séquence :

• 200 jours = 6 mois maximaux (184 jours) + 1/2 mois de 30 jours (15 jours) + 1 jour de marge de sécurité
• 100 jours = 3 mois maximaux (92 jours) + environ 1/4 mois de 30 jours (7 jours) + 1 jour de marge de sécurité
• 47 jours = 1 mois maximal (31 jours) + 1/2 mois de 30 jours (15 jours) + 1 jour de marge de sécurité

Ce modèle de définition d'une durée de validité « impaire » avec une marge de sécurité ajoutée est de longue date une pratique standard du CA/B Forum. La limite actuelle de 398 jours avait été choisie comme 1 année maximale (366 jours) + 1 mois maximal (31 jours) + 1 jour de marge de sécurité.

Oui, selon les règles, il est possible d'obtenir 398 jours supplémentaires si vous renouvelez les certificats avant le 15 mars 2026. Il s'agit toutefois d'une extension unique – lors du renouvellement suivant, la durée maximale sera diminuée à 100 jours. N'oubliez pas de définir l'automatisation à temps pour vous préparer.

Si vous devez réémettre le certificat avec une nouvelle clé (rekey) le 15 mars 2026 ou plus tard, DigiCert (comme toute autre autorité de certification publique) devra suivre les règles alors en vigueur, ce qui vous donnera dans le meilleur des cas un certificat valable 200 jours.

Le meilleur moment pour automatiser la gestion des certificats est le plus tôt possible — vous vous assurerez d'être prêt pour ce processus sans risquer de perturbations dues à des expirations de certificats ou à d'autres problèmes.

Le marché des certificats TLS publics est en grande partie axé sur les certificats utilisés dans les navigateurs, généralement installés sur un serveur Web, mais il existe d’autres cas d’utilisation. Un bon exemple est celui des passerelles VPN et de certains appareils de l’internet des objets (IoT).

Ces appareils devront également accélérer la gestion du cycle de vie des certificats (CLM). Beaucoup d'entre eux prennent en charge ACME ou un autre protocole d'automatisation, de sorte que modifier les paramètres ne devrait pas poser de problème majeur. Dans d'autres cas, il peut exister un mécanisme d'automatisation alternatif, ou pas de prise en charge du tout – dans ce cas, l'utilisateur devra s'assurer de l'automatisation par programmation.

Pour ces appareils, l’adaptation au nouveau calendrier sera souvent un problème. Il est important de créer un inventaire complet des actifs concernés, ce que peut faire DigiCert.