Ballot SC-085v2 : les autorités de certification vérifient désormais DNSSEC avant d'émettre un certificat TLS

⚡TL;DR

• Depuis le 15 mars 2026, les CA doivent vérifier DNSSEC lors de la validation de domaine (DCV) avant d'émettre un certificat TLS (Ballot SC-085v2)
• Si votre domaine publie DNSSEC et que la chaîne de confiance est cassée (BOGUS), aucun certificat ne sera émis tant que le problème persiste
• SC-085v2 complète MPIC (SC-067) : ensemble, ils protègent la DCV contre le BGP hijacking et le DNS spoofing
• SC-081v3 réduit aussi la durée de vie des certificats TLS à 47 jours d'ici 2029 : consultez notre guide complet SC-081v3

Depuis le 15 mars 2026, renouveler un certificat TLS peut échouer si votre domaine publie DNSSEC avec une chaîne de confiance invalide. Ce n'est pas un bug de votre fournisseur de certificats : c'est l'application du Ballot SC-085v2 du CA/Browser Forum, qui impose aux autorités de certification (CA) de valider les réponses DNSSEC lors de la vérification de contrôle de domaine.

Ce changement touche tous les domaines qui publient DNSSEC. Si votre zone DNS est correctement signée, vous bénéficiez d'une protection renforcée contre les attaques de type BGP hijacking et DNS spoofing lors de l'émission de certificats. Mais si votre configuration DNSSEC est cassée (enregistrement DS périmé, signatures expirées, algorithme obsolète), la CA refusera d'émettre le certificat.

Cet article détaille le problème que SC-085v2 résout, son fonctionnement technique, son interaction avec MPIC (SC-067), l'impact opérationnel selon votre situation et un guide pratique pour vérifier et corriger votre configuration avant le prochain renouvellement.

Le problème : la DCV repose sur un DNS non authentifié

La validation de contrôle de domaine (DCV) est le processus par lequel une CA vérifie que le demandeur d'un certificat contrôle effectivement le domaine concerné. Ce processus repose sur le DNS, un protocole conçu sans authentification des réponses.

Comment fonctionne la validation de domaine (DCV)

Avant d'émettre un certificat TLS, la CA doit s'assurer que vous contrôlez le domaine pour lequel vous demandez le certificat. Trois méthodes de validation sont couramment utilisées :

• DNS-01 : la CA demande de publier un enregistrement TXT spécifique sous _acme-challenge.captaindns.com. Elle interroge ensuite le DNS pour vérifier que l'enregistrement est présent et contient la valeur attendue. C'est la méthode la plus utilisée par les systèmes automatisés.
• HTTP-01 : la CA demande de placer un fichier à une URL spécifique sur le serveur web du domaine (par exemple http://captaindns.com/.well-known/acme-challenge/TOKEN). Elle vérifie ensuite que le fichier est accessible et contient la bonne valeur.
• Email : la CA envoie un email de validation à une adresse administrative du domaine (admin@, postmaster@, etc.) et attend une confirmation.

Le protocole ACME (Automatic Certificate Management Environment, RFC 8555) automatise ces échanges. Il standardise le dialogue entre le client (certbot, acme.sh, etc.) et la CA. La méthode DNS-01 est la plus répandue dans les environnements automatisés car elle permet de valider des certificats wildcard et ne nécessite pas d'exposer un serveur web.

Dans tous les cas, la CA effectue des requêtes DNS : pour résoudre le TXT de validation (DNS-01), pour résoudre l'adresse IP du serveur web (HTTP-01), ou pour résoudre le MX du domaine (email). Le DNS est donc le fondement de la DCV.

Le DNS sans DNSSEC est falsifiable

Le protocole DNS, conçu en 1983, n'intègre aucune authentification des réponses. Un résolveur DNS ne peut pas distinguer une réponse légitime d'une réponse forgée. Cette faiblesse structurelle ouvre la porte à plusieurs vecteurs d'attaque :

Cache poisoning. Un attaquant injecte de fausses réponses dans le cache d'un résolveur DNS. Les requêtes ultérieures pour le même domaine retournent l'adresse IP de l'attaquant au lieu de celle du serveur légitime.

BGP hijacking. Un attaquant annonce des routes BGP frauduleuses pour détourner le trafic réseau vers ses propres serveurs. Combiné à une requête DCV, il peut intercepter la validation et obtenir un certificat pour un domaine qu'il ne contrôle pas.

Attaque man-in-the-middle sur le réseau. Un attaquant positionné sur le chemin réseau entre la CA et le serveur DNS autoritaire modifie les réponses DNS en transit.

Ces attaques ne sont pas théoriques. Plusieurs incidents majeurs ont démontré leur faisabilité :

• KLAYswap (février 2022) : des attaquants ont détourné le trafic BGP d'un registre de domaine coréen, obtenu un certificat TLS frauduleux par BGP hijack, et volé l'équivalent de 2 millions de dollars en cryptomonnaie via un faux site.
• Celer Bridge (août 2022) : une attaque similaire a exploité le BGP hijacking pour détourner le trafic DNS d'un pont DeFi. Les attaquants ont obtenu un certificat frauduleux et volé 235 000 dollars.
• MyEtherWallet (avril 2018) : des attaquants ont détourné les préfixes BGP de Route 53 d'Amazon pour rediriger les requêtes DNS vers un serveur frauduleux, obtenu un certificat TLS et intercepté les identifiants des utilisateurs du portefeuille crypto.

La recherche académique a formalisé ces risques. L'étude "Bamboozling Certificate Authorities with BGP" (USENIX Security 2018, Princeton University) a démontré qu'un attaquant pouvait obtenir des certificats TLS frauduleux auprès des cinq plus grandes CA en détournant les requêtes DNS via BGP, avec un taux de succès supérieur à 60 % dans leurs expérimentations.

Le constat est clair : tant que la DCV repose sur un DNS non authentifié, l'émission de certificats TLS reste vulnérable.

Ballot SC-085v2 : ce que ça change concrètement

Le Ballot SC-085v2, intitulé "Require Validation of DNSSEC when Present for CAA and DCV Lookups", a été proposé par Clint Wilson (Apple) et soutenu par Chrome Root Program (Google), Fastly et HARICA. Il modifie les Baseline Requirements (BR) du CA/Browser Forum, le document normatif que toutes les CA publiquement approuvées doivent respecter.

Le vote

Le vote s'est conclu avec une adoption unanime côté navigateurs et quasi-unanime côté CA :

• 25 voix pour (dont DigiCert, Sectigo, GlobalSign, Entrust, HARICA, SwissSign)
• 0 voix contre
• 1 abstention (Entrust, qui a voté pour sur le plan technique mais s'est abstenu sur des questions de calendrier)
• Côté navigateurs : Apple et Mozilla ont voté pour

Ce que le ballot impose

Depuis le 15 mars 2026, les CA doivent effectuer une validation DNSSEC complète sur les requêtes DNS utilisées pour :

1. La validation de contrôle de domaine (DCV) : toutes les requêtes DNS liées à la vérification de contrôle (TXT pour DNS-01, A/AAAA pour HTTP-01, MX pour email)
2. Les vérifications CAA (Certification Authority Authorization) : les enregistrements CAA déterminent quelles CA sont autorisées à émettre des certificats pour un domaine

La validation DNSSEC doit être effectuée jusqu'au trust anchor IANA (la KSK racine) sur la Primary Network Perspective, c'est-à-dire le point de résolution principal de la CA. L'exigence couvre la chaîne complète : de la racine DNS au domaine cible, chaque signature RRSIG doit être vérifiée.

Ce que le ballot ne change pas

Les domaines sans DNSSEC ne sont pas affectés. Si votre domaine ne publie pas d'enregistrement DS au TLD, la CA continue la DCV exactement comme avant. SC-085v2 ne rend pas DNSSEC obligatoire pour obtenir un certificat. Il impose simplement aux CA de respecter DNSSEC quand il est déployé.

Calendrier de déploiement

Les principales CA ont anticipé l'échéance :

• DigiCert : validation DNSSEC active depuis le 3 mars 2026, avec le code erreur dns_sec_validation_error pour les domaines en échec
• Sectigo : déploiement achevé le 5 mars 2026
• Échéance officielle : 15 mars 2026, toutes les CA doivent être conformes

L'exception pour la validation par email (SC-094v2)

Le Ballot SC-094v2, adopté séparément, accorde une exception temporaire pour la DCV par email. Les méthodes de validation par email (BR sections 3.2.2.4.2 et 3.2.2.4.4) sont en cours de retrait progressif et bénéficient d'un délai supplémentaire avant que la validation DNSSEC ne leur soit imposée. Cette exception reconnaît que ces méthodes historiques seront progressivement abandonnées.

Comment DNSSEC sécurise l'émission de certificats

DNSSEC ajoute une couche d'authentification cryptographique au DNS. Chaque enregistrement DNS est accompagné d'une signature numérique (RRSIG) vérifiable par le résolveur. La confiance se propage du trust anchor IANA (la KSK racine) jusqu'au domaine cible via une chaîne d'enregistrements DS et de DNSKEY. Pour une explication détaillée de ce mécanisme, consultez notre guide sur la chaîne de confiance DNSSEC.

Application concrète à la DCV

Prenons un scénario concret. Un système automatisé demande un certificat pour captaindns.com via ACME (DNS-01). Le client ACME publie un enregistrement TXT sous _acme-challenge.captaindns.com avec un token unique.

La CA interroge le DNS pour récupérer ce TXT. Avec SC-085v2, le résolveur de la CA effectue désormais une validation DNSSEC complète :

1. Il vérifie que la zone captaindns.com publie un enregistrement DS au TLD .com
2. Il récupère les DNSKEY de la zone captaindns.com et vérifie que le DS correspond au hash de la KSK
3. Il vérifie que le RRSIG du TXT _acme-challenge.captaindns.com est signé par une ZSK dont la DNSKEY est elle-même signée par la KSK
4. Il remonte la chaîne jusqu'à la racine IANA pour valider chaque maillon

Si toutes les signatures sont valides, le résolveur retourne la réponse avec le flag AD (Authenticated Data). La CA peut alors procéder à la DCV avec la garantie que la réponse DNS n'a pas été falsifiée.

Les trois scénarios après SC-085v2

Scénario 1 : domaine sans DNSSEC. Votre domaine ne publie pas d'enregistrement DS au TLD. Le résolveur de la CA constate l'absence de DNSSEC et procède à la DCV classique, sans validation cryptographique. Aucun changement par rapport à avant SC-085v2.

Scénario 2 : DNSSEC valide (SECURE). Votre domaine publie DNSSEC et la chaîne de confiance est intacte. Le résolveur valide chaque signature, obtient le flag AD, et la CA procède à la DCV avec la certitude que la réponse est authentique. C'est le comportement idéal : vous bénéficiez d'une protection complète contre le spoofing DNS lors de l'émission de votre certificat.

Scénario 3 : DNSSEC cassé (BOGUS). Votre domaine publie un enregistrement DS au TLD, mais la validation échoue. Le DS ne correspond pas à la DNSKEY, les RRSIG sont expirées, ou un algorithme non pris en charge est utilisé. Le résolveur marque la réponse comme BOGUS et retourne un SERVFAIL. La CA ne peut pas obtenir de réponse DNS valide et refuse d'émettre le certificat.

Le RFC 4035 section 5 définit l'algorithme de validation que les résolveurs (et donc les CA) doivent implémenter. Les CA conformes à SC-085v2 appliquent cet algorithme sur leur Primary Network Perspective pour toute requête DCV et CAA.

MPIC et DNSSEC : la défense en profondeur

SC-085v2 ne fonctionne pas en isolation. Il s'inscrit dans une stratégie de défense en profondeur initiée par le CA/Browser Forum, dont le premier volet est MPIC (Multi-Perspective Issuance Corroboration).

MPIC : la protection réseau

Le Ballot SC-067v3, effectif depuis mars 2025, impose aux CA de valider la DCV depuis au moins deux perspectives réseau géographiquement séparées (minimum 500 km). Concrètement, quand vous demandez un certificat, la CA lance la vérification DNS depuis plusieurs points de présence à travers le monde.

L'objectif : contrer les attaques BGP localisées. Si un attaquant détourne le trafic BGP dans une région, les perspectives réseau situées dans d'autres régions recevront la réponse DNS légitime. La CA détecte l'incohérence et refuse d'émettre le certificat.

DNSSEC : la protection au niveau du protocole

SC-085v2 ajoute une deuxième couche de protection, cette fois au niveau du protocole DNS lui-même. DNSSEC garantit l'authenticité des réponses DNS via des signatures cryptographiques. Même si l'attaquant contrôle le chemin réseau, il ne peut pas forger une réponse DNS valide sans posséder les clés privées de la zone.

Pourquoi les deux sont nécessaires

MPIC et DNSSEC adressent des vecteurs d'attaque différents et se complètent :

• MPIC seul ne protège pas si le serveur DNS autoritaire est compromis ou si l'attaquant a empoisonné les caches DNS de manière globale. Toutes les perspectives réseau recevraient la même fausse réponse.
• DNSSEC seul ne protège pas si le résolveur de la CA ne valide pas DNSSEC (ce qui n'est plus possible avec SC-085v2 quand DNSSEC est publié), ou si l'attaque cible le chemin réseau sans modifier les réponses DNS.
• Ensemble : MPIC couvre le vecteur réseau (BGP hijacking localisé), DNSSEC couvre le vecteur DNS (spoofing, cache poisoning). Un attaquant devrait simultanément compromettre la chaîne DNSSEC et détourner le trafic depuis toutes les perspectives réseau de la CA pour obtenir un certificat frauduleux.

Impact opérationnel : qui est concerné ?

L'impact de SC-085v2 dépend directement de votre situation DNSSEC. Voici les quatre profils types et leurs conséquences.

DNSSEC actif et correctement configuré

Si votre domaine publie DNSSEC avec une chaîne de confiance intacte, SC-085v2 ne change rien à votre flux opérationnel. Vos renouvellements de certificats continuent de fonctionner normalement. La seule différence : la CA valide désormais cryptographiquement les réponses DNS, ce qui renforce la sécurité de l'émission. Vous êtes protégé contre les attaques de type BGP hijacking et DNS spoofing ciblant la DCV.

C'est le scénario idéal. Votre investissement dans DNSSEC paye doublement : protection DNS classique et protection de l'émission de certificats.

DNSSEC actif mais mal configuré

C'est le scénario à risque. Votre domaine publie un enregistrement DS au TLD, ce qui indique aux résolveurs que la zone est signée. Mais la configuration DNSSEC est invalide. Plusieurs causes fréquentes :

• Enregistrement DS périmé après une migration DNS. Vous avez changé de fournisseur DNS, le nouveau fournisseur a généré de nouvelles clés DNSSEC, mais l'enregistrement DS au registrar pointe encore vers les anciennes clés. La chaîne est cassée.
• RRSIG expirées. Les signatures DNSSEC ont une durée de vie limitée (typiquement 7 à 30 jours). Si le processus de re-signature automatique échoue silencieusement, les RRSIG expirent et la zone devient BOGUS.
• Rotation KSK/ZSK incorrecte. Une rotation de clé mal séquencée (nouvelle clé publiée avant propagation du DS, ou ancien DS supprimé avant propagation de la nouvelle clé) casse temporairement la chaîne.
• Algorithme non pris en charge. Certains anciens algorithmes (RSA-SHA1, DSA) sont dépréciés. Si votre zone utilise un algorithme que le résolveur de la CA ne prend pas en charge, la validation échoue.

Avant SC-085v2, une configuration DNSSEC cassée provoquait des SERVFAIL pour les résolveurs validants (1.1.1.1, 8.8.8.8, 9.9.9.9) mais n'empêchait pas l'émission de certificats, car les résolveurs des CA ne validaient pas systématiquement DNSSEC. Désormais, un DNSSEC BOGUS bloque la DCV et le certificat est refusé.

Pas de DNSSEC déployé

Si votre domaine ne publie pas d'enregistrement DS au TLD, SC-085v2 n'a aucun impact immédiat. La CA constate l'absence de DNSSEC et procède à la DCV classique. Vos renouvellements continuent de fonctionner exactement comme avant.

Cependant, l'adoption de DNSSEC devient de plus en plus stratégique. SC-085v2 crée une incitation forte : les domaines avec DNSSEC valide bénéficient d'une DCV protégée contre le spoofing. Les domaines sans DNSSEC restent vulnérables aux mêmes attaques que celles décrites dans la section précédente. La migration de Microsoft 365 vers le domaine mx.microsoft avec DNSSEC automatique, l'arrivée de DMARCbis qui recommande DNSSEC pour la protection des enregistrements MX, et SC-085v2 convergent vers un écosystème où DNSSEC devient la norme attendue.

Certificats automatisés via ACME

Ce profil mérite une attention particulière. La méthode DNS-01 est massivement utilisée par les systèmes ACME pour valider les certificats, en particulier pour les certificats wildcard. Si votre infrastructure automatise le renouvellement via certbot, acme.sh ou un opérateur Kubernetes comme cert-manager, le flux est entièrement non interactif.

Le risque : un DNSSEC cassé provoque un échec silencieux. Le renouvellement ACME échoue, le certificat expire, et votre site devient inaccessible en HTTPS. Aucune intervention humaine n'est dans la boucle pour détecter le problème avant l'expiration.

DigiCert a introduit le code erreur dns_sec_validation_error pour signaler spécifiquement un échec de validation DNSSEC lors de la DCV. Si vous recevez cette erreur, le problème est dans votre configuration DNSSEC, pas dans votre enregistrement de validation.

Adoption DNSSEC : état des lieux en mars 2026

Comprendre le niveau d'adoption actuel permet de mesurer l'ampleur du changement introduit par SC-085v2.

Validation globale

Environ 35 % des requêtes DNS mondiales transitent par des résolveurs qui valident DNSSEC. Ce chiffre reflète l'adoption côté résolveurs : les grands résolveurs publics (1.1.1.1, 8.8.8.8, 9.9.9.9) valident tous DNSSEC. Les résolveurs FAI sont plus hétérogènes, mais la tendance est à la hausse.

Taux de signature par TLD

L'adoption de DNSSEC par les domaines (côté zone, pas côté résolveur) varie considérablement selon les TLD :

• .nl (Pays-Bas) : environ 60 % des domaines signés. Premier mondial grâce à l'incitation active du SIDN (registre du .nl).
• TLD nordiques (.se, .dk, .no) : plus de 50 % d'adoption, portée par des registres proactifs.
• .com : environ 4 à 5 % des domaines signés. Le volume est énorme en valeur absolue, mais le pourcentage reste faible.
• 92 % des TLD ont un enregistrement DS dans la zone racine, ce qui signifie que l'infrastructure de signature existe au niveau TLD.

L'asymétrie entre infrastructure et adoption

L'infrastructure de validation DNSSEC est largement déployée. Les résolveurs sont prêts. Les TLD sont signés. Mais la signature des zones individuelles reste minoritaire. Cette asymétrie s'explique par la complexité perçue du déploiement DNSSEC et l'absence jusqu'ici de conséquences visibles pour les domaines non signés.

SC-085v2 change cette dynamique. Pour la première fois, il y a une conséquence concrète à publier DNSSEC avec une configuration invalide. Et il y a un bénéfice mesurable à publier DNSSEC correctement : la protection de la DCV.

L'effet domino est prévisible. SC-085v2, combiné à la migration Microsoft 365 vers mx.microsoft avec DNSSEC automatique et aux recommandations DMARCbis, va accélérer l'adoption de DNSSEC au cours des prochains trimestres.

Guide pratique : vérifier et corriger sa configuration DNSSEC

Avant votre prochain renouvellement de certificat, vérifiez que votre configuration DNSSEC est intacte. Voici les commandes et étapes essentielles.

Vérification rapide avec dig

Vérifier le flag AD (Authenticated Data) :

dig +dnssec SOA captaindns.com

Dans la section flags:, recherchez ad. Sa présence signifie que le résolveur a validé la chaîne DNSSEC avec succès. Son absence indique soit que DNSSEC n'est pas déployé, soit que la validation a échoué.

Vérifier les enregistrements DS au TLD :

dig DS captaindns.com +short

Cette commande retourne le ou les enregistrements DS publiés par le registrar au TLD. Si la réponse est vide, votre domaine ne publie pas DNSSEC. Si des DS sont présents, vérifiez qu'ils correspondent aux clés actuelles de votre zone.

Vérifier les clés DNSKEY :

dig DNSKEY captaindns.com +short

Vous devez voir au minimum deux clés : une avec le flag 256 (ZSK) et une avec le flag 257 (KSK). Le hash de la KSK (flag 257) doit correspondre à l'enregistrement DS publié au TLD.

Distinguer un problème DNSSEC d'un autre problème DNS :

dig captaindns.com +cd

Le flag +cd (Checking Disabled) désactive la validation DNSSEC. Si la requête fonctionne avec +cd mais échoue sans (SERVFAIL), le problème est DNSSEC.

Que faire si DNSSEC est cassé

Si vos vérifications révèlent un problème, voici les actions correctives par ordre de priorité :

Vérifier l'enregistrement DS chez le registrar. Connectez-vous à l'interface de votre registrar et comparez l'enregistrement DS publié avec la DNSKEY (flag 257) de votre zone. Si vous avez migré de fournisseur DNS, le DS doit pointer vers la KSK du nouveau fournisseur.

Vérifier les RRSIG dans la zone. Les signatures ont une date d'expiration. Si votre fournisseur DNS a un problème de re-signature, les RRSIG peuvent être expirées. Contactez votre fournisseur DNS ou vérifiez les logs de signature si vous gérez DNSSEC en interne.

Vérifier l'algorithme. Les algorithmes RSA-SHA1 et DSA sont dépréciés. Privilégiez ECDSAP256SHA256 (algorithme 13) ou ECDSAP384SHA384 (algorithme 14).

Pour un diagnostic détaillé des erreurs SERVFAIL liées à DNSSEC, consultez notre guide dédié : résoudre SERVFAIL après DNSSEC. Si vous devez activer DNSSEC pour la première fois, suivez notre guide d'activation DNSSEC pas à pas.

Liste de contrôle pré-renouvellement certificat

Avant chaque renouvellement de certificat sur un domaine avec DNSSEC :

• L'enregistrement DS au registrar correspond à la KSK active de la zone
• Les RRSIG ne sont pas expirées (vérifier l'inception et l'expiration avec dig +dnssec)
• L'algorithme utilisé est pris en charge (ECDSAP256SHA256 recommandé)
• Le résolveur retourne le flag AD pour votre domaine
• La surveillance DNSSEC est en place et envoie des alertes en cas de rupture de chaîne
• Un dry-run ACME a été exécuté avec succès sur le domaine concerné

SC-081 et l'accélération des renouvellements

Le Ballot SC-081, adopté par le CA/Browser Forum, réduit progressivement la durée maximale des certificats TLS :

Date d'application	Durée maximale
Mars 2026	200 jours
Mars 2027	100 jours
Mars 2029	47 jours

Cette réduction a un impact direct sur la criticité de SC-085v2. Plus la durée des certificats est courte, plus les renouvellements sont fréquents. Et plus les renouvellements sont fréquents, plus un DNSSEC cassé sera détecté rapidement, mais aussi plus il sera bloquant.

Avec des certificats de 200 jours, un problème DNSSEC qui dure une semaine retarde un renouvellement. Avec des certificats de 47 jours, un problème DNSSEC de quelques jours peut provoquer l'expiration du certificat avant que le renouvellement ne réussisse. La marge d'erreur se réduit drastiquement.

À 47 jours, l'automatisation ACME devient incontournable. Aucune organisation ne peut gérer manuellement des renouvellements toutes les six semaines sur un parc de domaines. Et un pipeline ACME automatisé qui échoue silencieusement à cause d'un DNSSEC cassé est un scénario d'incident majeur.

La recommandation est claire : mettez en place une surveillance DNSSEC continue sur tous vos domaines avec certificats TLS. Configurez des alertes sur l'expiration des RRSIG (au moins 7 jours avant expiration) et sur la correspondance DS/DNSKEY. Intégrez la vérification DNSSEC dans votre pipeline de renouvellement ACME, avant la demande de certificat.

Plan d'action : préparer votre infrastructure

1. Vérifier l'état DNSSEC de tous vos domaines avec le DNSSEC Checker de CaptainDNS
2. Corriger les chaînes cassées : enregistrement DS manquant, signature expirée, algorithme incompatible
3. Auditer les certificats actifs : lister les domaines DNSSEC avec certificats à renouveler dans les 90 jours
4. Configurer la surveillance : alertes sur expiration RRSIG et expiration certificat
5. Tester le renouvellement : lancer un dry-run ACME sur les domaines DNSSEC
6. Documenter : ajouter la vérification DNSSEC à votre procédure de renouvellement

FAQ

Le Ballot SC-085v2 rend-il DNSSEC obligatoire pour obtenir un certificat TLS ?

Non. SC-085v2 impose aux CA de valider DNSSEC quand il est présent, mais ne rend pas DNSSEC obligatoire. Si votre domaine ne publie pas d'enregistrement DS au TLD, la CA procède à la DCV classique sans validation DNSSEC. Vous pouvez obtenir un certificat TLS sans DNSSEC, exactement comme avant.

Que se passe-t-il si mon DNSSEC est cassé lors du renouvellement automatique ?

Le renouvellement échoue. La CA retourne une erreur de type dns_sec_validation_error (chez DigiCert) ou un SERVFAIL. Le client ACME ne peut pas compléter la validation DNS-01 et le certificat n'est pas renouvelé. Si le problème persiste jusqu'à l'expiration du certificat actuel, votre site devient inaccessible en HTTPS. C'est pourquoi une surveillance DNSSEC avec alertes est indispensable.

Quelles CA sont concernées par SC-085v2 ?

Toutes les CA publiquement approuvées (c'est-à-dire dont le certificat racine est inclus dans les magasins de confiance des navigateurs). Cela inclut DigiCert, Sectigo, Let's Encrypt, GlobalSign, Entrust, HARICA, SwissSign et toutes les autres CA conformes aux Baseline Requirements du CA/Browser Forum. Les CA privées (internes à une organisation) ne sont pas concernées.

Let's Encrypt validait-il déjà DNSSEC ?

Let's Encrypt utilisait déjà des résolveurs validants DNSSEC (Unbound) dans son infrastructure. En pratique, un domaine avec DNSSEC BOGUS pouvait déjà échouer la validation chez Let's Encrypt. SC-085v2 formalise cette exigence dans les Baseline Requirements et l'étend à toutes les CA, pas seulement celles qui avaient choisi de valider DNSSEC.

Quelle est la différence entre MPIC (SC-067) et SC-085v2 ?

MPIC (SC-067) protège la DCV au niveau réseau en vérifiant depuis plusieurs points géographiques. Il détecte les attaques BGP localisées. SC-085v2 protège la DCV au niveau DNS en vérifiant les signatures DNSSEC. Il détecte les réponses DNS falsifiées. Les deux sont complémentaires : MPIC couvre le vecteur BGP, DNSSEC couvre le vecteur DNS.

Mon certificat actuel sera-t-il révoqué si DNSSEC casse après émission ?

Non. SC-085v2 concerne uniquement la validation au moment de l'émission. Un certificat déjà émis reste valide jusqu'à son expiration, même si DNSSEC casse après l'émission. En revanche, le prochain renouvellement échouera tant que DNSSEC est BOGUS.

Comment savoir si mon domaine publie DNSSEC ?

Exécutez dig DS captaindns.com +short (remplacez par votre domaine). Si la commande retourne un ou plusieurs enregistrements DS, votre domaine publie DNSSEC. Si la réponse est vide, DNSSEC n'est pas activé. Vous pouvez aussi utiliser le DNSSEC Checker de CaptainDNS pour un diagnostic complet incluant la validation de la chaîne de confiance.

SC-085v2 affecte-t-il les certificats wildcard ?

Oui. Les certificats wildcard sont validés via DNS-01 (la seule méthode ACME compatible wildcard). La CA interroge le DNS pour vérifier le TXT _acme-challenge et applique la validation DNSSEC sur cette requête. Si DNSSEC est BOGUS pour votre domaine, le certificat wildcard ne sera pas émis.

Quel est le lien avec le Ballot SC-081 sur la réduction de durée des certificats ?

SC-081 réduit la durée maximale des certificats TLS (200 jours en 2026, 100 jours en 2027, 47 jours en 2029). Des certificats plus courts impliquent des renouvellements plus fréquents. Chaque renouvellement déclenche une DCV, et chaque DCV inclut désormais la validation DNSSEC (SC-085v2). Un DNSSEC cassé bloque donc plus souvent le renouvellement, avec moins de marge avant expiration.

Dois-je activer DNSSEC pour bénéficier de la protection SC-085v2 ?

Oui. SC-085v2 protège uniquement les domaines qui publient DNSSEC. Sans DNSSEC, la CA ne peut pas vérifier l'authenticité des réponses DNS et la DCV reste vulnérable au spoofing. Activer DNSSEC sur votre domaine est le seul moyen de bénéficier de cette protection renforcée lors de l'émission de certificats.

Glossaire

• CA (Certificate Authority) : autorité de certification habilitée à émettre des certificats TLS. Les CA publiques sont incluses dans les magasins de confiance des navigateurs et soumises aux Baseline Requirements du CA/Browser Forum.
• DCV (Domain Control Validation) : processus par lequel une CA vérifie que le demandeur d'un certificat contrôle effectivement le domaine. Méthodes courantes : DNS-01, HTTP-01, email.
• CA/Browser Forum : consortium regroupant les CA et les éditeurs de navigateurs. Il définit les Baseline Requirements, le cadre normatif que toutes les CA publiques doivent respecter.
• MPIC (Multi-Perspective Issuance Corroboration) : mécanisme imposé par le Ballot SC-067, obligeant les CA à valider la DCV depuis au moins deux perspectives réseau géographiquement distantes pour contrer le BGP hijacking.
• BOGUS : état interne du résolveur DNSSEC quand la validation cryptographique échoue. Un domaine BOGUS provoque un SERVFAIL pour le client. Après SC-085v2, un domaine BOGUS bloque aussi l'émission de certificats.
• 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 et cert-manager.
• Baseline Requirements (BR) : document normatif du CA/Browser Forum définissant les exigences minimales pour l'émission de certificats TLS par les CA publiques. SC-085v2 modifie les BR pour imposer la validation DNSSEC.

Sources

1. Ballot SC-085v2 : Require Validation of DNSSEC for CAA and DCV Lookups (CA/Browser Forum)
2. Ballot SC-067v3 : Require Multi-Perspective Issuance Corroboration (CA/Browser Forum)
3. DigiCert : Validating DNSSEC for Domain Control and CAA Checks
4. RFC 4035 : Protocol Modifications for DNS Security Extensions (IETF)
5. DNSSEC Deployment Statistics (APNIC)