SC-081v3 : des certificats TLS de 47 jours, pourquoi et comment s'y préparer

⚡TL;DR

• SC-081v3 adopté : la durée de vie maximale des certificats TLS passe de 398 jours à 47 jours d'ici mars 2029, en 3 phases (200j en 2026, 100j en 2027, 47j en 2029)
• La réutilisation DCV chute aussi : de 398 jours à 10 jours, imposant une revalidation de domaine quasi continue à chaque renouvellement
• L'automatisation n'est plus optionnelle : sans ACME ou équivalent, le renouvellement manuel tous les 47 jours est intenable
• Découvrez aussi comment SC-085v2 impose la validation DNSSEC par les CA, une mesure complémentaire entrée en vigueur le même jour

Le 15 mars 2026 marque un point de basculement pour l'écosystème TLS. Deux ballots du CA/Browser Forum entrent en vigueur simultanément : SC-085v2, qui impose aux autorités de certification de valider DNSSEC lors de l'émission de certificats, et la première phase de SC-081v3, qui réduit la durée maximale des certificats TLS de 398 à 200 jours. La coïncidence n'est pas fortuite : les deux textes participent à la même refonte de la confiance sur le web.

SC-081v3 a été adopté par le CA/Browser Forum en avril 2025 avec un soutien massif : 25 voix pour, 0 contre, 5 abstentions. Apple, à l'origine de la proposition, a été rejoint par Google, Mozilla et Microsoft. Le message est clair : l'ère des certificats d'un an est révolue. D'ici mars 2029, la durée maximale d'un certificat TLS sera de 47 jours, et la réutilisation des preuves de validation de domaine (DCV) sera limitée à 10 jours.

Cet article couvre l'historique complet des réductions de durée, le détail du ballot SC-081v3, les raisons techniques de ce changement, les pannes qui ont accéléré la décision, l'automatisation ACME, le rôle de Let's Encrypt, l'impact sur les certificats payants, l'interaction avec SC-085v2 et DNSSEC, et un guide pratique pour préparer votre infrastructure.

De 10 ans à 47 jours : l'histoire de la réduction

La durée de vie des certificats TLS n'a cessé de diminuer depuis la création du système. Chaque réduction a provoqué des résistances, puis une adaptation rapide de l'industrie. Le schéma est constant : un acteur impose un changement, l'écosystème s'adapte, et personne ne revient en arrière.

Avant 2012 : jusqu'à 10 ans. Les premières versions des certificats SSL n'imposaient aucune limite stricte de durée. Des certificats de 8 à 10 ans circulaient. La révocation reposait sur des listes CRL rarement consultées. Le risque de compromission sur une telle durée était considérable, mais le coût des certificats (plusieurs centaines de dollars) incitait à maximiser leur durée de vie.

2012 : 5 ans (Baseline Requirements v1). Le CA/Browser Forum publie la première version des Baseline Requirements. La durée maximale est fixée à 60 mois. C'est la première normalisation globale des pratiques d'émission de certificats TLS.

2015 : 39 mois. Le Ballot 193 réduit la durée à 39 mois. L'industrie s'adapte sans incident majeur. Les certificats de 3 ans deviennent la norme pour les clients entreprise.

2018 : 825 jours. Nouvelle réduction à 825 jours (environ 27 mois) via le Ballot 193 révisé. Les certificats de 2 ans s'imposent. Let's Encrypt, lancé en 2015, a déjà popularisé les certificats de 90 jours et démontré que l'automatisation fonctionne à grande échelle.

2020 : 398 jours (décision unilatérale Apple). Apple annonce unilatéralement en février 2020 que Safari n'acceptera plus les certificats de plus de 398 jours émis après le 1er septembre 2020. Google et Mozilla suivent dans les semaines qui suivent. Le CA/Browser Forum n'a pas eu besoin de voter : les éditeurs de navigateurs ont imposé le changement via leurs root programs. L'industrie grogne, mais s'adapte en quelques mois.

2023 : Google propose 90 jours. Dans sa feuille de route "Moving Forward, Together", Google propose de réduire la durée maximale à 90 jours. La proposition ne fait pas l'objet d'un vote immédiat mais lance le débat.

2024 : SC-081v1 retiré, v2 échoue. La première version du ballot est retirée avant vote. SC-081v2 est soumis au vote mais échoue à obtenir la super-majorité requise. Plusieurs CA s'opposent au calendrier jugé trop agressif. Les ballots SC-22 et 185, qui visaient des réductions similaires, avaient déjà échoué les années précédentes.

Avril 2025 : SC-081v3 adopté. La troisième version trouve le consensus. Le calendrier est étalé sur 4 phases entre 2026 et 2029, laissant le temps à l'industrie de s'adapter. Le vote : 25 pour, 0 contre, 5 abstentions.

Le schéma est limpide : chaque réduction a été combattue, puis adoptée, puis considérée comme insuffisante quelques années plus tard. La direction est irréversible.

Ballot SC-081v3 : ce que ça change concrètement

SC-081v3 ne se contente pas de raccourcir la durée des certificats. Il réduit aussi la période de réutilisation des preuves de validation de domaine (DCV reuse), forçant une revalidation quasi continue.

Les 4 phases de la réduction

Phase	Date d'entrée en vigueur	Durée max. certificat	Réutilisation DCV max.
Phase 0 (actuelle)	Avant le 15 mars 2026	398 jours	398 jours
Phase 1	15 mars 2026	200 jours	200 jours
Phase 2	15 mars 2027	100 jours	100 jours
Phase 3	15 mars 2029	47 jours	10 jours

Comprendre la réutilisation DCV

La validation de contrôle de domaine (DCV) est le processus par lequel une CA vérifie que le demandeur contrôle le domaine. Actuellement, une preuve DCV peut être réutilisée pendant 398 jours : si vous validez votre domaine aujourd'hui, la CA peut émettre un nouveau certificat dans les 398 jours suivants sans redemander de preuve.

SC-081v3 réduit cette fenêtre de réutilisation en parallèle de la durée des certificats. En phase 3, la réutilisation DCV tombe à 10 jours. Concrètement, chaque renouvellement de certificat nécessitera une nouvelle validation de domaine, puisqu'un certificat de 47 jours doit être renouvelé avant expiration et que la preuve DCV ne sera valide que 10 jours.

Pourquoi 47 jours et pas un nombre rond ?

Le chiffre 47 n'est pas arbitraire. Il correspond à un cycle de renouvellement de 30 jours avec un tampon de 17 jours. L'idée : si le client ACME renouvelle le certificat 30 jours avant expiration (comme le recommandent la plupart des clients), il reste 17 jours de marge en cas d'échec. Un renouvellement par mois, avec un filet de sécurité de plus de deux semaines.

Ce qui ne change pas

SC-081v3 s'applique à tous les types de certificats TLS publics : DV (Domain Validation), OV (Organization Validation) et EV (Extended Validation). Il n'y a pas d'exception pour les certificats OV ou EV, contrairement à ce que certains commentateurs avaient espéré. La distinction DV/OV/EV porte sur le niveau de vérification de l'identité de l'organisation, pas sur la durée du certificat.

Les tentatives échouées

SC-081v3 n'est pas la première tentative de réduction. Plusieurs ballots avaient échoué au fil des ans. Le Ballot 185 (2017) proposait de passer à 13 mois et a été rejeté. Le Ballot SC-22 a tenté une réduction à 397 jours et a échoué. SC-081v1 a été retiré avant vote. SC-081v2 n'a pas obtenu la super-majorité côté CA. La v3 a réussi en étalant le calendrier et en ajoutant un tampon suffisant à chaque phase.

Pourquoi des certificats plus courts ?

La réduction de la durée des certificats répond à plusieurs problèmes structurels de l'écosystème TLS. Aucun d'entre eux ne peut être résolu par les mécanismes actuels.

La révocation est cassée

Le mécanisme prévu pour invalider un certificat compromis ne fonctionne pas en pratique. Les listes de révocation (CRL) atteignent des centaines de mégaoctets : la CRL de Let's Encrypt dépassait 300 Mo avant l'abandon d'OCSP. OCSP (Online Certificate Status Protocol) souffre du problème du soft-fail : si le serveur OCSP ne répond pas, le navigateur accepte le certificat par défaut, rendant la vérification inutile. Chrome a remplacé OCSP par CRLSets, une liste compacte qui ne couvre qu'environ 2 % des certificats révoqués. Let's Encrypt a officiellement abandonné OCSP fin 2024, reconnaissant l'échec du mécanisme.

Avec des certificats de 47 jours, la révocation devient moins critique. Un certificat compromis expire naturellement en quelques semaines, limitant la fenêtre d'exploitation sans dépendre d'un mécanisme de révocation défaillant.

Crypto-agilité et migration post-quantique

Des certificats courts facilitent la migration vers de nouveaux algorithmes cryptographiques. Le NIST a publié en août 2024 les standards finaux pour la cryptographie post-quantique : ML-KEM (Key Encapsulation) et ML-DSA (Digital Signatures). La transition vers ces algorithmes nécessitera de remplacer les certificats existants. Avec des certificats de 47 jours, l'écosystème entier migre en 47 jours maximum, contre plus d'un an avec des certificats de 398 jours.

Fenêtre de compromission réduite

Un certificat compromis de 398 jours peut être exploité pendant plus d'un an. Avec 47 jours, la fenêtre d'exploitation maximale passe à moins de 7 semaines. C'est une réduction de 88 %. Si une clé privée est volée, l'attaquant dispose de quelques semaines au lieu de plus d'un an pour l'exploiter.

L'automatisation forcée réduit les pannes

Paradoxalement, des certificats plus courts réduisent les pannes liées à l'expiration. La raison : ils forcent l'automatisation. Un certificat de 398 jours peut être géré manuellement (mal), oublié, puis expirer brutalement. Un certificat de 47 jours ne laisse pas le choix : sans automatisation, le renouvellement est impossible à maintenir. Les organisations qui automatisent ne subissent plus de pannes d'expiration.

Alignement avec le modèle zero trust

Le modèle Zero Trust repose sur la vérification continue. Un certificat de 398 jours accorde une confiance implicite pendant plus d'un an, ce qui contredit le principe. Des certificats courts imposent une re-vérification fréquente de l'identité du serveur, alignant la PKI web avec les principes Zero Trust.

Les pannes qui ont tout changé

Plusieurs incidents majeurs ont démontré les conséquences d'une gestion manuelle des certificats. Chaque panne a renforcé l'argument en faveur de l'automatisation et de la réduction de durée.

Equifax (2017) : 147,9 millions de personnes exposées

En mars 2015, Equifax laisse expirer un certificat SSL sur un équipement d'inspection du trafic réseau. Ce certificat périmé depuis 19 mois empêche la détection d'une intrusion active. Les attaquants exploitent une vulnérabilité Apache Struts non corrigée pendant 76 jours, exfiltrant les données personnelles de 147,9 millions de personnes. Le coût total dépasse 1,38 milliard de dollars. L'enquête révèle que l'entreprise gérait plus de 300 certificats manuellement, sans inventaire centralisé.

Ericsson/O2 UK (2018) : 32 millions d'utilisateurs sans réseau

Le 6 décembre 2018, un certificat intermédiaire Ericsson expire sur l'infrastructure réseau d'O2 UK. L'expiration provoque une panne totale du réseau mobile pour 32 millions d'abonnés pendant plus de 12 heures. SoftBank au Japon subit une panne identique le même jour. Le coût estimé dépasse 133 millions de dollars. Le certificat, avec une durée de vie de 15 ans, avait été installé et oublié.

Microsoft Teams (2020) : 3 heures de panne mondiale

Le 3 février 2020, Microsoft Teams subit une panne de 3 heures en pleine montée en charge liée au COVID-19. La cause : un certificat d'authentification expiré. L'incident touche des millions d'utilisateurs en télétravail au moment où Teams est devenu un outil critique pour des milliers d'entreprises.

Let's Encrypt (2021) : l'expiration d'un certificat racine historique

Le 30 septembre 2021, le certificat racine DST Root CA X3, utilisé par Let's Encrypt pour la compatibilité avec les anciens appareils, expire. Des millions d'appareils sous Android 7.1 et versions antérieures perdent l'accès à des sites utilisant Let's Encrypt. L'incident illustre la complexité de la gestion des certificats racine et la nécessité de chaînes de confiance agiles.

Le point commun de ces incidents : chaque panne implique un certificat géré manuellement, oublié, ou dont la durée de vie dépassait largement les besoins opérationnels.

ACME et l'automatisation obligatoire

Avec des certificats de 47 jours et une réutilisation DCV de 10 jours, le renouvellement manuel devient physiquement impossible pour toute infrastructure comptant plus d'une poignée de certificats. ACME (Automatic Certificate Management Environment) est le protocole qui rend l'automatisation possible.

Le protocole ACME (RFC 8555)

ACME standardise le dialogue entre un client (votre serveur) et une CA. Le processus suit trois étapes : le client prouve qu'il contrôle le domaine (challenge), la CA vérifie la preuve, puis émet le certificat. Trois types de challenges existent :

• HTTP-01 : le client place un fichier à une URL spécifique. La CA vérifie que le fichier est accessible. Simple mais incompatible avec les certificats wildcard.
• DNS-01 : le client publie un enregistrement TXT sous _acme-challenge.captaindns.com. La CA interroge le DNS. Compatible wildcard, idéal pour les environnements automatisés.
• TLS-ALPN-01 : le client configure un certificat temporaire avec une extension ALPN spécifique. Utile quand on ne contrôle ni le DNS ni le serveur web.

Clients ACME

L'écosystème des clients ACME est mature et couvre tous les environnements :

• Certbot : le client de référence, maintenu par l'EFF. Compatible Linux, macOS, Windows. Plugins pour Apache et NGINX.
• acme.sh : script shell pur, sans dépendance. Plus de 150 API DNS prises en charge pour le challenge dns-01.
• Lego : client Go, populaire dans les environnements containerisés et les pipelines CI/CD.
• Caddy : serveur web avec ACME intégré. Obtient et renouvelle les certificats automatiquement, sans configuration.
• Traefik : reverse proxy cloud-native avec ACME intégré. Gère les certificats pour tous les backends.

ACME dans le cloud

Les principaux fournisseurs cloud intègrent l'automatisation des certificats :

• AWS Certificate Manager (ACM) : certificats gratuits avec renouvellement automatique pour les services AWS (ALB, CloudFront, API Gateway).
• Google Cloud Managed Certificates : renouvellement automatique pour les load balancers GCP.
• Azure App Service Managed Certificates : certificats gratuits et renouvelés automatiquement.
• Cloudflare : certificats edge et origin gérés automatiquement, avec support des certificats de 15 jours.

ACME renewal information (ARI, RFC 9773)

ARI est une extension ACME qui permet à la CA de communiquer au client la fenêtre optimale de renouvellement. Au lieu de renouveler systématiquement à un pourcentage fixe de la durée restante, le client interroge la CA pour connaître le moment idéal. Cela permet à la CA de lisser la charge et de signaler un renouvellement anticipé en cas de compromission de clé. Let's Encrypt supporte ARI depuis 2024.

NGINX et le module ACME natif

En août 2025, NGINX a publié un module natif ACME permettant au serveur web d'obtenir et de renouveler ses certificats directement, sans client externe. Cette intégration simplifie considérablement le déploiement pour les environnements qui utilisent NGINX en frontal.

Solutions entreprise

Pour les grandes organisations gérant des milliers de certificats, des solutions CLM (Certificate Lifecycle Management) orchestrent le renouvellement à l'échelle :

• HashiCorp Vault PKI : moteur PKI intégré à Vault, avec émission et rotation automatisées.
• Venafi / CyberArk : plateforme CLM enterprise (CyberArk a racheté Venafi pour 1,54 milliard de dollars en 2024).
• Keyfactor : plateforme de gestion du cycle de vie des certificats et des identités machine.
• Sectigo Certificate Manager : CLM avec ACME intégré, couvrant les certificats publics et privés.

Let's Encrypt en éclaireur

Let's Encrypt n'a pas attendu SC-081v3 pour pousser l'industrie vers des certificats courts. L'autorité de certification gratuite et automatisée détient environ 63,9 % de part de marché des certificats TLS web et émet plus de 10 millions de certificats par jour. Son influence sur l'écosystème est considérable.

Certificats de 6 jours en production

Depuis janvier 2026, Let's Encrypt propose des certificats de 6 jours en disponibilité générale. Ces certificats ultra-courts ciblent les environnements hautement automatisés (CDN, plateformes cloud, CI/CD) où le renouvellement est entièrement piloté par ACME. L'objectif : prouver que des durées de vie très courtes fonctionnent à l'échelle industrielle.

Vers des certificats de 45 jours par défaut

Let's Encrypt a annoncé un plan de transition vers des certificats de 45 jours par défaut. Le calendrier prévoit une phase opt-in à partir de mai 2026, suivie d'un passage au défaut de 45 jours en février 2028. Cette anticipation du calendrier SC-081v3 (qui impose 47 jours en mars 2029) donne à l'écosystème un an d'avance pour valider les pipelines d'automatisation.

L'abandon d'OCSP

Fin 2024, Let's Encrypt a annoncé l'abandon progressif d'OCSP, achevé en 2025. La raison : OCSP ne fonctionne pas (soft-fail dans les navigateurs, problèmes de vie privée, charge serveur). Ce choix a accéléré la réflexion de l'industrie sur la révocation et renforcé l'argument des certificats courts. Si la révocation ne fonctionne pas, la seule alternative est de limiter la durée de vie des certificats.

Let's Encrypt prouve chaque jour que l'automatisation à grande échelle est viable. Plus de 400 millions de sites web utilisent ses certificats. Le passage à 47 jours ne sera pas un problème pour les environnements déjà automatisés : ce sera un non-événement.

Impact sur les certificats payants et l'écosystème CA

SC-081v3 transforme le modèle économique des autorités de certification et remet en question la valeur ajoutée des certificats payants.

OV et EV : toujours valables, mais plus courts

Les certificats OV (Organization Validation) et EV (Extended Validation) restent disponibles. La validation d'organisation (vérification de l'identité de l'entreprise, adresse, numéro d'enregistrement) continue d'apporter une valeur distincte de la simple validation de domaine. Mais la durée du certificat est réduite de la même manière : 200 jours en 2026, 100 jours en 2027, 47 jours en 2029. Un certificat EV de 47 jours impose le même rythme de renouvellement qu'un certificat DV.

Le pivot vers les abonnements et le CLM

Les CA payantes pivotent leur modèle économique. Au lieu de vendre des certificats unitaires à durée fixe, elles proposent des abonnements annuels incluant des renouvellements illimités et un client ACME intégré. DigiCert, Sectigo et GlobalSign proposent tous des plateformes CLM (Certificate Lifecycle Management) qui automatisent le renouvellement ACME pour les certificats OV et EV.

La consolidation du marché CA

Le rachat de Venafi par CyberArk pour 1,54 milliard de dollars en 2024 illustre la consolidation du marché. La valeur se déplace de l'émission de certificats vers la gestion du cycle de vie. Les CA qui ne proposent pas d'automatisation intégrée perdent des parts de marché face à Let's Encrypt et aux solutions CLM.

Wildcards et multi-SAN

Les certificats wildcard (*.captaindns.com) et multi-SAN (plusieurs domaines sur un seul certificat) nécessitent le challenge DNS-01 pour la validation. Avec des renouvellements tous les 47 jours, l'automatisation du challenge dns-01 via l'API du fournisseur DNS devient indispensable. Les fournisseurs DNS majeurs (Cloudflare, AWS Route 53, Google Cloud DNS, Azure DNS) proposent tous des API compatibles avec les clients ACME.

L'automatisation remet en question le certificat payant

L'automatisation ACME nivelle le terrain. Un certificat DV gratuit Let's Encrypt, renouvelé automatiquement tous les 47 jours, offre le même niveau de chiffrement qu'un certificat EV payant. La différence se limite à la barre d'adresse du navigateur (qui n'affiche plus le nom de l'organisation depuis 2019) et à la garantie financière associée au certificat. Pour la majorité des sites web, cette différence ne justifie plus le surcoût.

Interaction avec SC-085v2 : DNSSEC et renouvellements fréquents

SC-081v3 et SC-085v2 entrent en vigueur le même mois et créent un effet multiplicateur sur la chaîne de confiance DNS. Pour comprendre SC-085v2 en détail, consultez notre article dédié.

L'effet multiplicateur

Avec SC-085v2, chaque validation de domaine (DCV) inclut désormais une vérification DNSSEC. Avec SC-081v3 phase 3, un certificat de 47 jours implique environ 8 renouvellements par an au lieu de 1. Chaque renouvellement déclenche une DCV, et chaque DCV vérifie DNSSEC. Le nombre de vérifications DNSSEC liées aux certificats est donc multiplié par 8.

Scénario de panne : DNSSEC cassé + certificats courts

Considérons un scénario concret. Votre certificat TLS expire dans 15 jours. Votre client ACME tente le renouvellement. La CA effectue la validation DNS-01 et vérifie DNSSEC conformément à SC-085v2. Mais une rotation de clé DNSSEC a échoué : l'enregistrement DS au TLD ne correspond plus à la KSK de votre zone. Le résolveur de la CA retourne BOGUS, la DCV échoue, le certificat n'est pas renouvelé.

Avec un certificat de 398 jours, vous avez des mois pour détecter et corriger le problème. Avec un certificat de 47 jours, vous avez au mieux 17 jours (le tampon intégré au cycle de renouvellement). Si le problème DNSSEC persiste, votre certificat expire et votre site devient inaccessible.

Rotation DANE/TLSA et certificats courts

Si vous utilisez DANE pour authentifier vos certificats TLS via des enregistrements TLSA signés par DNSSEC, la rotation des enregistrements TLSA doit suivre le rythme des renouvellements de certificats. Avec un certificat de 47 jours, l'enregistrement TLSA doit être mis à jour à chaque renouvellement (sauf en mode DANE-EE 3 1 1 avec SPKI, qui survit au renouvellement si la clé publique ne change pas). Consultez notre guide DANE/TLSA pour les stratégies de rotation.

Pipeline unifié : la recommandation

La combinaison SC-081v3 + SC-085v2 impose une approche unifiée. Le pipeline de renouvellement de certificats doit intégrer :

1. Le renouvellement ACME du certificat TLS
2. La vérification préalable de la chaîne DNSSEC
3. La mise à jour des enregistrements DANE/TLSA si nécessaire
4. La surveillance continue des trois composants

Traiter ces éléments séparément multiplie les points de défaillance. Un pipeline unifié qui vérifie DNSSEC avant de lancer le renouvellement ACME, puis met à jour TLSA après l'émission, réduit considérablement le risque de panne.

Guide pratique : préparer votre infrastructure

La transition vers des certificats de 47 jours se fait en 4 phases sur 3 ans. Chaque phase impose des contraintes plus strictes. Voici les 6 étapes pour préparer votre infrastructure.

Étape 1 : inventorier tous vos certificats

Avant d'automatiser, il faut savoir ce que vous gérez. Utilisez plusieurs sources pour dresser un inventaire complet :

• Certificate Transparency logs : interrogez les logs CT (crt.sh) pour lister tous les certificats émis pour vos domaines.
• Scan réseau : utilisez des outils comme sslyze ou nmap pour découvrir les certificats actifs sur votre infrastructure.
• Outils CLM : des plateformes comme Keyfactor ou Venafi Discovery scannent votre réseau et vos clouds pour identifier les certificats non répertoriés.
• Notre DNSSEC Checker : vérifiez la chaîne de confiance DNSSEC, indispensable pour le renouvellement de certificats depuis SC-085v2.

Documentez pour chaque certificat : le domaine, la CA émettrice, la date d'expiration, le type (DV/OV/EV), le mode de renouvellement (manuel ou automatisé) et le responsable.

Étape 2 : déployer un client ACME adapté

Choisissez un client ACME adapté à votre environnement :

• Serveur web standalone : Certbot avec le plugin approprié (Apache, NGINX) ou Caddy avec ACME intégré.
• Environnement containerisé : cert-manager pour Kubernetes, Lego pour les pipelines CI/CD.
• Infrastructure cloud : AWS ACM, Google Cloud Managed Certificates ou Azure App Service Managed Certificates.
• Environnement mixte : acme.sh pour sa flexibilité et sa compatibilité avec plus de 150 API DNS.

Testez le renouvellement avec un dry-run avant de passer en production. Validez que le client peut renouveler sans intervention humaine.

Étape 3 : automatiser la validation DNS

Pour le challenge dns-01 (requis pour les certificats wildcard), votre client ACME doit pouvoir créer et supprimer des enregistrements TXT via l'API de votre fournisseur DNS. Configurez les accès API avec des permissions minimales : création et suppression d'enregistrements TXT sous _acme-challenge uniquement.

Si votre fournisseur DNS ne propose pas d'API, migrez vers un fournisseur qui en propose. En 2026, l'absence d'API DNS est un facteur bloquant.

Étape 4 : vérifier votre chaîne DNSSEC

Avec SC-085v2, une chaîne DNSSEC cassée bloque le renouvellement de certificats. Vérifiez :

• La présence et la validité de l'enregistrement DS au TLD
• La cohérence entre le DS et la KSK publiée dans votre zone
• La validité des signatures RRSIG (dates d'expiration)
• L'automatisation de la rotation des clés ZSK et KSK

Consultez notre guide sur la chaîne de confiance DNSSEC pour les détails techniques. Utilisez le DNSSEC Checker pour un diagnostic complet.

Étape 5 : mettre en place la surveillance

Déployez des alertes sur trois axes :

• Expiration des certificats TLS : alerte à 30 jours, 14 jours et 7 jours avant expiration.
• Signatures DNSSEC (RRSIG) : alerte quand les signatures approchent de leur date d'expiration.
• Enregistrements DANE/TLSA : vérification que les enregistrements TLSA correspondent au certificat actif.

La surveillance est le filet de sécurité qui détecte les échecs d'automatisation avant qu'ils ne deviennent des pannes.

Étape 6 : planifier la migration progressive

N'attendez pas mars 2029 pour passer à 47 jours. Adoptez un plan progressif :

• Dès maintenant : automatisez tous les certificats avec des durées de 90 jours (Let's Encrypt par défaut).
• 2026 : testez les certificats de 6 jours de Let's Encrypt sur un environnement de staging.
• 2027 : passez en production avec des certificats de 100 jours ou moins.
• 2028 : activez les certificats de 45 jours Let's Encrypt (opt-in) pour valider votre pipeline avant l'échéance.
• 2029 : le passage à 47 jours est un non-événement, votre infrastructure est prête.

Plan d'action : préparer votre infrastructure

1. Inventorier tous vos certificats : discovery via CT logs, scan réseau, outils CLM
2. Déployer un client ACME : Certbot, acme.sh ou Lego selon l'environnement
3. Automatiser la validation DNS : API fournisseur DNS pour le challenge dns-01
4. Vérifier DNSSEC : chaîne de confiance valide, rotations de clés automatisées
5. Mettre en place la surveillance : alertes expiration certificats + RRSIG + TLSA
6. Tester avec des certificats courts : Let's Encrypt 90j puis 6j pour valider le pipeline

FAQ

Qu'est-ce que le Ballot SC-081v3 du CA/Browser Forum ?

SC-081v3 est un ballot adopté en avril 2025 par le CA/Browser Forum qui réduit progressivement la durée de vie maximale des certificats TLS publics. La durée passe de 398 jours à 200 jours (mars 2026), puis 100 jours (mars 2027), puis 47 jours (mars 2029). Il réduit aussi la période de réutilisation des preuves de validation de domaine (DCV) jusqu'à 10 jours en phase finale.

Quand les certificats de 47 jours deviennent-ils obligatoires ?

Les certificats de 47 jours maximum deviennent obligatoires le 15 mars 2029 (phase 3 du ballot). Avant cette date, deux phases intermédiaires s'appliquent : 200 jours maximum dès le 15 mars 2026 et 100 jours maximum dès le 15 mars 2027. Les certificats émis avant chaque date limite restent valides jusqu'à leur expiration naturelle.

Mes certificats actuels vont-ils être révoqués ?

Non. Les certificats déjà émis restent valides jusqu'à leur date d'expiration, quelle que soit la phase en cours. SC-081v3 s'applique uniquement aux nouveaux certificats émis après chaque date d'entrée en vigueur. Un certificat de 398 jours émis le 14 mars 2026 restera valide pendant toute sa durée.

Pourquoi 47 jours et pas un nombre rond ?

Le chiffre 47 correspond à un cycle de renouvellement de 30 jours plus un tampon de 17 jours. Si le client ACME renouvelle 30 jours avant expiration (la pratique recommandée), il reste 17 jours de marge en cas d'échec du renouvellement. Ce tampon permet de détecter et corriger les problèmes avant l'expiration effective du certificat.

Les certificats EV et OV sont-ils concernés ?

Oui. SC-081v3 s'applique à tous les types de certificats TLS publics, y compris DV, OV et EV. Il n'y a aucune exception. La distinction entre ces types porte sur le niveau de vérification de l'identité de l'organisation, pas sur la durée du certificat. Un certificat EV sera limité à 47 jours comme un certificat DV à partir de mars 2029.

Qu'est-ce que la réduction de la réutilisation DCV ?

La réutilisation DCV (Domain Control Validation) permet à une CA de réutiliser une preuve de contrôle de domaine pour émettre plusieurs certificats sans redemander de validation. SC-081v3 réduit cette fenêtre de 398 jours à 10 jours en phase finale. Concrètement, chaque renouvellement de certificat en phase 3 nécessitera une nouvelle preuve de contrôle du domaine.

Dois-je passer à Let's Encrypt ?

Pas nécessairement. Let's Encrypt est une option solide pour les certificats DV automatisés, mais d'autres CA supportent aussi ACME : DigiCert, Sectigo, GlobalSign et ZeroSSL proposent toutes des endpoints ACME. Si vous avez besoin de certificats OV ou EV, vous devrez rester chez une CA payante, mais avec un client ACME pour le renouvellement automatisé.

Comment fonctionne ACME pour le renouvellement automatique ?

ACME (RFC 8555) automatise le dialogue entre votre serveur et la CA. Le client ACME prouve que vous contrôlez le domaine (via un challenge HTTP-01, DNS-01 ou TLS-ALPN-01), la CA vérifie la preuve, puis émet le certificat. Le client planifie ensuite le renouvellement automatique avant expiration. Tout le processus se déroule sans intervention humaine.

Quel est le lien entre SC-081v3 et SC-085v2 (DNSSEC) ?

SC-085v2 impose aux CA de valider DNSSEC lors de la DCV. SC-081v3 multiplie les DCV en raccourcissant la durée des certificats. Combinés, ces deux ballots créent un effet multiplicateur : 8 renouvellements par an (47 jours) signifient 8 vérifications DNSSEC au lieu de 1. Un DNSSEC cassé bloque donc plus rapidement et plus fréquemment le renouvellement de vos certificats.

Les certificats internes (PKI privée) sont-ils concernés ?

Non. SC-081v3 s'applique uniquement aux certificats émis par des CA publiquement approuvées (celles dont le certificat racine est inclus dans les magasins de confiance des navigateurs). Les certificats émis par une PKI privée interne à votre organisation ne sont pas soumis aux Baseline Requirements du CA/Browser Forum et ne sont pas affectés par cette réduction.

Glossaire

• CA/Browser Forum : consortium regroupant les autorités de certification et les éditeurs de navigateurs. Il publie les Baseline Requirements, le cadre normatif que toutes les CA publiques doivent respecter pour que leurs certificats soient acceptés par les navigateurs.
• Ballot : proposition de modification des Baseline Requirements soumise au vote des membres du CA/Browser Forum. Un ballot doit obtenir une super-majorité côté CA et l'unanimité côté navigateurs pour être adopté.
• DCV (Domain Control Validation) : processus par lequel une CA vérifie que le demandeur d'un certificat contrôle effectivement le domaine. Les méthodes courantes sont DNS-01, HTTP-01 et email. La réutilisation DCV permet de réutiliser une preuve existante pour des émissions ultérieures.
• ACME (Automatic Certificate Management Environment) : protocole standardisé (RFC 8555) pour l'automatisation de l'émission et du renouvellement de certificats TLS. Utilisé par Let's Encrypt, certbot, acme.sh, Lego et cert-manager.
• CRL (Certificate Revocation List) : liste de certificats révoqués publiée par une CA. Les CRL sont volumineuses (plusieurs centaines de Mo) et rarement consultées par les navigateurs, ce qui limite leur efficacité.
• OCSP (Online Certificate Status Protocol) : protocole de vérification en temps réel du statut de révocation d'un certificat. En pratique, les navigateurs ignorent les erreurs OCSP (soft-fail), rendant le mécanisme inefficace. Let's Encrypt a abandonné OCSP en 2025.
• Crypto-agilité : capacité d'un système à migrer rapidement vers de nouveaux algorithmes cryptographiques. Des certificats courts facilitent cette migration en limitant la durée pendant laquelle un algorithme obsolète reste en service.
• DANE/TLSA : protocole permettant de publier dans le DNS (via des enregistrements TLSA signés par DNSSEC) le certificat attendu sur un serveur. Élimine la dépendance aux CA pour l'authentification du certificat.

Sources

1. Ballot SC-081v3 : Reduce Validity and Data Reuse Periods (CA/Browser Forum)
2. Let's Encrypt : Decreasing Certificate Lifetimes to 45 Days
3. Google : Moving Forward, Together (Chrome Root Program)
4. RFC 8555 : Automatic Certificate Management Environment (ACME)
5. APNIC : Certificate lifetimes are getting shorter