Ballot SC-085v2: le autorità di certificazione verificano DNSSEC prima di emettere un certificato TLS

⚡TL;DR

• Dal 15 marzo 2026 le CA devono verificare DNSSEC durante la validazione del dominio (DCV) prima di emettere un certificato TLS (Ballot SC-085v2)
• Se il tuo dominio pubblica DNSSEC e la catena di fiducia è rotta (BOGUS), nessun certificato verrà emesso finché il problema persiste
• SC-085v2 completa MPIC (SC-067): insieme proteggono la DCV contro il BGP hijacking e il DNS spoofing
• SC-081v3 riduce anche la durata dei certificati TLS a 47 giorni entro il 2029: consulta la nostra guida completa SC-081v3

Dal 15 marzo 2026, rinnovare un certificato TLS può fallire se il tuo dominio pubblica DNSSEC con una catena di fiducia non valida. Non si tratta di un bug del tuo fornitore di certificati: è l'applicazione del Ballot SC-085v2 del CA/Browser Forum, che impone alle autorità di certificazione (CA) di validare le risposte DNSSEC durante la verifica del controllo di dominio.

Questo cambiamento riguarda tutti i domini che pubblicano DNSSEC. Se la tua zona DNS è correttamente firmata, benefici di una protezione rafforzata contro attacchi di tipo BGP hijacking e DNS spoofing durante l'emissione dei certificati. Ma se la tua configurazione DNSSEC è rotta (DS record scaduto, firme scadute, algoritmo obsoleto), la CA rifiuterà di emettere il certificato.

Questo articolo descrive in dettaglio il problema che SC-085v2 risolve, il suo funzionamento tecnico, l'interazione con MPIC (SC-067), l'impatto operativo in base alla tua situazione e una guida pratica per verificare e correggere la configurazione prima del prossimo rinnovo.

Il problema: la DCV si basa su un DNS non autenticato

La validazione del controllo di dominio (DCV) è il processo con cui una CA verifica che il richiedente di un certificato controlla effettivamente il dominio in questione. Questo processo si basa sul DNS, un protocollo progettato senza autenticazione delle risposte.

Come funziona la validazione del dominio (DCV)

Prima di emettere un certificato TLS, la CA deve assicurarsi che tu controlli il dominio per il quale richiedi il certificato. Tre metodi di validazione sono comunemente utilizzati:

• DNS-01: la CA chiede di pubblicare un record TXT specifico sotto _acme-challenge.captaindns.com. Interroga poi il DNS per verificare che il record sia presente e contenga il valore atteso. È il metodo più usato dai sistemi automatizzati.
• HTTP-01: la CA chiede di inserire un file a un URL specifico sul server web del dominio (ad esempio http://captaindns.com/.well-known/acme-challenge/TOKEN). Verifica poi che il file sia accessibile e contenga il valore corretto.
• Email: la CA invia un'email di validazione a un indirizzo amministrativo del dominio (admin@, postmaster@, ecc.) e attende una conferma.

Il protocollo ACME (Automatic Certificate Management Environment, RFC 8555) automatizza questi scambi. Standardizza il dialogo tra il client (certbot, acme.sh, ecc.) e la CA. Il metodo DNS-01 è il più diffuso negli ambienti automatizzati perché permette di validare certificati wildcard e non richiede di esporre un server web.

In tutti i casi, la CA effettua query DNS: per risolvere il TXT di validazione (DNS-01), per risolvere l'indirizzo IP del server web (HTTP-01), o per risolvere il MX del dominio (email). Il DNS è quindi il fondamento della DCV.

Il DNS senza DNSSEC è falsificabile

Il protocollo DNS, progettato nel 1983, non prevede alcuna autenticazione delle risposte. Un resolver DNS non può distinguere una risposta legittima da una risposta contraffatta. Questa debolezza strutturale apre la porta a diversi vettori di attacco:

Cache poisoning. Un attaccante inietta risposte false nella cache di un resolver DNS. Le query successive per lo stesso dominio restituiscono l'indirizzo IP dell'attaccante invece di quello del server legittimo.

BGP hijacking. Un attaccante annuncia route BGP fraudolente per dirottare il traffico di rete verso i propri server. Combinato con una richiesta DCV, può intercettare la validazione e ottenere un certificato per un dominio che non controlla.

Attacco man-in-the-middle sulla rete. Un attaccante posizionato sul percorso di rete tra la CA e il server DNS autoritativo modifica le risposte DNS in transito.

Questi attacchi non sono teorici. Diversi incidenti significativi ne hanno dimostrato la fattibilità:

• KLAYswap (febbraio 2022): degli attaccanti hanno dirottato il traffico BGP di un registro di dominio coreano, ottenuto un certificato TLS fraudolento tramite BGP hijack, e rubato l'equivalente di 2 milioni di dollari in criptovaluta tramite un sito falso.
• Celer Bridge (agosto 2022): un attacco simile ha sfruttato il BGP hijacking per dirottare il traffico DNS di un bridge DeFi. Gli attaccanti hanno ottenuto un certificato fraudolento e rubato 235.000 dollari.
• MyEtherWallet (aprile 2018): degli attaccanti hanno dirottato i prefissi BGP di Route 53 di Amazon per reindirizzare le query DNS verso un server fraudolento, ottenuto un certificato TLS e intercettato le credenziali degli utenti del wallet crypto.

La ricerca accademica ha formalizzato questi rischi. Lo studio "Bamboozling Certificate Authorities with BGP" (USENIX Security 2018, Princeton University) ha dimostrato che un attaccante poteva ottenere certificati TLS fraudolenti dalle cinque principali CA dirottando le query DNS via BGP, con un tasso di successo superiore al 60% nei loro esperimenti.

La conclusione è chiara: finché la DCV si basa su un DNS non autenticato, l'emissione di certificati TLS resta vulnerabile.

Ballot SC-085v2: cosa cambia concretamente

Il Ballot SC-085v2, intitolato "Require Validation of DNSSEC when Present for CAA and DCV Lookups", è stato proposto da Clint Wilson (Apple) e supportato da Chrome Root Program (Google), Fastly e HARICA. Modifica i Baseline Requirements (BR) del CA/Browser Forum, il documento normativo che tutte le CA pubblicamente approvate devono rispettare.

Il voto

Il voto si è concluso con un'adozione unanime lato browser e quasi unanime lato CA:

• 25 voti a favore (tra cui DigiCert, Sectigo, GlobalSign, Entrust, HARICA, SwissSign)
• 0 voti contrari
• 1 astensione (Entrust, che ha votato a favore sul piano tecnico ma si è astenuto su questioni di tempistica)
• Lato browser: Apple e Mozilla hanno votato a favore

Cosa impone il ballot

Dal 15 marzo 2026, le CA devono effettuare una validazione DNSSEC completa sulle query DNS utilizzate per:

1. La validazione del controllo di dominio (DCV): tutte le query DNS legate alla verifica di controllo (TXT per DNS-01, A/AAAA per HTTP-01, MX per email)
2. Le verifiche CAA (Certification Authority Authorization): i record CAA determinano quali CA sono autorizzate a emettere certificati per un dominio

La validazione DNSSEC deve essere effettuata fino al trust anchor IANA (la KSK radice) sulla Primary Network Perspective, cioè il punto di risoluzione principale della CA. Il requisito copre la catena completa: dalla radice DNS al dominio di destinazione, ogni firma RRSIG deve essere verificata.

Cosa non cambia il ballot

I domini senza DNSSEC non sono interessati. Se il tuo dominio non pubblica un DS record al TLD, la CA prosegue con la DCV esattamente come prima. SC-085v2 non rende DNSSEC obbligatorio per ottenere un certificato. Impone semplicemente alle CA di rispettare DNSSEC quando è implementato.

Timeline di implementazione

Le principali CA hanno anticipato la scadenza:

• DigiCert: validazione DNSSEC attiva dal 3 marzo 2026, con il codice errore dns_sec_validation_error per i domini in errore
• Sectigo: implementazione completata il 5 marzo 2026
• Scadenza ufficiale: 15 marzo 2026, tutte le CA devono essere conformi

L'eccezione per la validazione via email (SC-094v2)

Il Ballot SC-094v2, adottato separatamente, concede un'eccezione temporanea per la DCV via email. I metodi di validazione via email (BR sezioni 3.2.2.4.2 e 3.2.2.4.4) sono in via di dismissione e beneficiano di una proroga prima che la validazione DNSSEC venga loro imposta. Questa eccezione riconosce che questi metodi storici verranno progressivamente abbandonati.

Come DNSSEC protegge l'emissione dei certificati

DNSSEC aggiunge un livello di autenticazione crittografica al DNS. Ogni record DNS è accompagnato da una firma digitale (RRSIG) verificabile dal resolver. La fiducia si propaga dal trust anchor IANA (la KSK radice) fino al dominio di destinazione attraverso una catena di DS record e di DNSKEY. Per una spiegazione dettagliata di questo meccanismo, consulta la nostra guida sulla catena di fiducia DNSSEC.

Applicazione concreta alla DCV

Prendiamo uno scenario concreto. Un sistema automatizzato richiede un certificato per captaindns.com tramite ACME (DNS-01). Il client ACME pubblica un record TXT sotto _acme-challenge.captaindns.com con un token univoco.

La CA interroga il DNS per recuperare questo TXT. Con SC-085v2, il resolver della CA effettua ora una validazione DNSSEC completa:

1. Verifica che la zona captaindns.com pubblichi un DS record al TLD .com
2. Recupera le DNSKEY della zona captaindns.com e verifica che il DS corrisponda all'hash della KSK
3. Verifica che il RRSIG del TXT _acme-challenge.captaindns.com sia firmato da una ZSK la cui DNSKEY è a sua volta firmata dalla KSK
4. Risale la catena fino alla radice IANA per validare ogni anello

Se tutte le firme sono valide, il resolver restituisce la risposta con il flag AD (Authenticated Data). La CA può quindi procedere con la DCV con la garanzia che la risposta DNS non è stata falsificata.

I tre scenari dopo SC-085v2

Scenario 1: dominio senza DNSSEC. Il tuo dominio non pubblica un DS record al TLD. Il resolver della CA constata l'assenza di DNSSEC e procede con la DCV classica, senza validazione crittografica. Nessun cambiamento rispetto a prima di SC-085v2.

Scenario 2: DNSSEC valido (SECURE). Il tuo dominio pubblica DNSSEC e la catena di fiducia è intatta. Il resolver valida ogni firma, ottiene il flag AD, e la CA procede con la DCV con la certezza che la risposta è autentica. È il comportamento ideale: benefici di una protezione completa contro lo spoofing DNS durante l'emissione del tuo certificato.

Scenario 3: DNSSEC rotto (BOGUS). Il tuo dominio pubblica un DS record al TLD, ma la validazione fallisce. Il DS non corrisponde alla DNSKEY, i RRSIG sono scaduti, o viene utilizzato un algoritmo non supportato. Il resolver contrassegna la risposta come BOGUS e restituisce un SERVFAIL. La CA non può ottenere una risposta DNS valida e rifiuta di emettere il certificato.

L'RFC 4035 sezione 5 definisce l'algoritmo di validazione che i resolver (e quindi le CA) devono implementare. Le CA conformi a SC-085v2 applicano questo algoritmo sulla loro Primary Network Perspective per ogni query DCV e CAA.

MPIC e DNSSEC: la difesa in profondità

SC-085v2 non funziona in isolamento. Si inserisce in una strategia di difesa in profondità avviata dal CA/Browser Forum, il cui primo elemento è MPIC (Multi-Perspective Issuance Corroboration).

MPIC: la protezione di rete

Il Ballot SC-067v3, in vigore da marzo 2025, impone alle CA di validare la DCV da almeno due prospettive di rete geograficamente separate (minimo 500 km). Concretamente, quando richiedi un certificato, la CA lancia la verifica DNS da più punti di presenza nel mondo.

L'obiettivo: contrastare gli attacchi BGP localizzati. Se un attaccante dirotta il traffico BGP in una regione, le prospettive di rete situate in altre regioni riceveranno la risposta DNS legittima. La CA rileva l'incoerenza e rifiuta di emettere il certificato.

DNSSEC: la protezione a livello di protocollo

SC-085v2 aggiunge un secondo livello di protezione, questa volta a livello del protocollo DNS stesso. DNSSEC garantisce l'autenticità delle risposte DNS tramite firme crittografiche. Anche se l'attaccante controlla il percorso di rete, non può falsificare una risposta DNS valida senza possedere le chiavi private della zona.

Perché entrambi sono necessari

MPIC e DNSSEC affrontano vettori di attacco diversi e si completano a vicenda:

• Solo MPIC non protegge se il server DNS autoritativo è compromesso o se l'attaccante ha avvelenato le cache DNS in modo globale. Tutte le prospettive di rete riceverebbero la stessa risposta falsa.
• Solo DNSSEC non protegge se il resolver della CA non valida DNSSEC (cosa non più possibile con SC-085v2 quando DNSSEC è pubblicato), o se l'attacco prende di mira il percorso di rete senza modificare le risposte DNS.
• Insieme: MPIC copre il vettore di rete (BGP hijacking localizzato), DNSSEC copre il vettore DNS (spoofing, cache poisoning). Un attaccante dovrebbe simultaneamente compromettere la catena DNSSEC e dirottare il traffico da tutte le prospettive di rete della CA per ottenere un certificato fraudolento.

Impatto operativo: chi è coinvolto?

L'impatto di SC-085v2 dipende direttamente dalla tua situazione DNSSEC. Ecco i quattro profili tipo e le relative conseguenze.

DNSSEC attivo e correttamente configurato

Se il tuo dominio pubblica DNSSEC con una catena di fiducia intatta, SC-085v2 non cambia nulla nel tuo flusso operativo. I rinnovi dei certificati continuano a funzionare normalmente. L'unica differenza: la CA ora valida crittograficamente le risposte DNS, il che rafforza la sicurezza dell'emissione. Sei protetto contro gli attacchi di tipo BGP hijacking e DNS spoofing che prendono di mira la DCV.

È lo scenario ideale. Il tuo investimento in DNSSEC ripaga doppiamente: protezione DNS classica e protezione dell'emissione dei certificati.

DNSSEC attivo ma mal configurato

È lo scenario a rischio. Il tuo dominio pubblica un DS record al TLD, il che indica ai resolver che la zona è firmata. Ma la configurazione DNSSEC non è valida. Diverse cause frequenti:

• DS record scaduto dopo una migrazione DNS. Hai cambiato fornitore DNS, il nuovo fornitore ha generato nuove chiavi DNSSEC, ma il DS record al registrar punta ancora alle vecchie chiavi. La catena è rotta.
• RRSIG scaduti. Le firme DNSSEC hanno una durata di vita limitata (tipicamente da 7 a 30 giorni). Se il processo di ri-firma automatico fallisce silenziosamente, i RRSIG scadono e la zona diventa BOGUS.
• Rotazione KSK/ZSK errata. Una rotazione delle chiavi mal sequenziata (nuova chiave pubblicata prima della propagazione del DS, o vecchio DS rimosso prima della propagazione della nuova chiave) rompe temporaneamente la catena.
• Algoritmo non supportato. Alcuni vecchi algoritmi (RSA-SHA1, DSA) sono deprecati. Se la tua zona utilizza un algoritmo che il resolver della CA non supporta, la validazione fallisce.

Prima di SC-085v2, una configurazione DNSSEC rotta provocava SERVFAIL per i resolver validanti (1.1.1.1, 8.8.8.8, 9.9.9.9) ma non impediva l'emissione dei certificati, perché i resolver delle CA non validavano sistematicamente DNSSEC. Ora, un DNSSEC BOGUS blocca la DCV e il certificato viene rifiutato.

Nessun DNSSEC implementato

Se il tuo dominio non pubblica un DS record al TLD, SC-085v2 non ha alcun impatto immediato. La CA constata l'assenza di DNSSEC e procede con la DCV classica. I tuoi rinnovi continuano a funzionare esattamente come prima.

Tuttavia, l'adozione di DNSSEC diventa sempre più strategica. SC-085v2 crea un forte incentivo: i domini con DNSSEC valido beneficiano di una DCV protetta contro lo spoofing. I domini senza DNSSEC restano vulnerabili agli stessi attacchi descritti nella sezione precedente. La migrazione di Microsoft 365 verso il dominio mx.microsoft con DNSSEC automatico, l'arrivo di DMARCbis che raccomanda DNSSEC per la protezione dei record MX, e SC-085v2 convergono verso un ecosistema dove DNSSEC diventa la norma attesa.

Certificati automatizzati via ACME

Questo profilo merita un'attenzione particolare. Il metodo DNS-01 è largamente utilizzato dai sistemi ACME per validare i certificati, in particolare per i certificati wildcard. Se la tua infrastruttura automatizza il rinnovo tramite certbot, acme.sh o un operatore Kubernetes come cert-manager, il flusso è interamente non interattivo.

Il rischio: un DNSSEC rotto provoca un fallimento silenzioso. Il rinnovo ACME fallisce, il certificato scade, e il tuo sito diventa inaccessibile in HTTPS. Nessun intervento umano è previsto nel processo per rilevare il problema prima della scadenza.

DigiCert ha introdotto il codice errore dns_sec_validation_error per segnalare specificamente un fallimento della validazione DNSSEC durante la DCV. Se ricevi questo errore, il problema è nella tua configurazione DNSSEC, non nel tuo record di validazione.

Adozione DNSSEC: stato dell'arte a marzo 2026

Comprendere il livello di adozione attuale permette di misurare la portata del cambiamento introdotto da SC-085v2.

Validazione globale

Circa il 35% delle query DNS mondiali transita attraverso resolver che validano DNSSEC. Questa cifra riflette l'adozione lato resolver: i grandi resolver pubblici (1.1.1.1, 8.8.8.8, 9.9.9.9) validano tutti DNSSEC. I resolver degli ISP sono più eterogenei, ma la tendenza è in crescita.

Tasso di firma per TLD

L'adozione di DNSSEC da parte dei domini (lato zona, non lato resolver) varia considerevolmente in base ai TLD:

• .nl (Paesi Bassi): circa il 60% dei domini firmati. Leader mondiale grazie all'incentivazione attiva del SIDN (registro del .nl).
• TLD nordici (.se, .dk, .no): oltre il 50% di adozione, sostenuta da registri proattivi.
• .com: circa il 4-5% dei domini firmati. Il volume è enorme in valore assoluto, ma la percentuale resta bassa.
• Il 92% dei TLD ha un DS record nella zona radice, il che significa che l'infrastruttura di firma esiste a livello di TLD.

L'asimmetria tra infrastruttura e adozione

L'infrastruttura di validazione DNSSEC è ampiamente implementata. I resolver sono pronti. I TLD sono firmati. Ma la firma delle zone individuali resta minoritaria. Questa asimmetria si spiega con la complessità percepita dell'implementazione DNSSEC e l'assenza, finora, di conseguenze visibili per i domini non firmati.

SC-085v2 cambia questa dinamica. Per la prima volta, c'è una conseguenza concreta nel pubblicare DNSSEC con una configurazione non valida. E c'è un beneficio misurabile nel pubblicare DNSSEC correttamente: la protezione della DCV.

L'effetto domino è prevedibile. SC-085v2, combinato con la migrazione Microsoft 365 verso mx.microsoft con DNSSEC automatico e le raccomandazioni DMARCbis, accelererà l'adozione di DNSSEC nei prossimi trimestri.

Guida pratica: verificare e correggere la configurazione DNSSEC

Prima del tuo prossimo rinnovo di certificato, verifica che la tua configurazione DNSSEC sia intatta. Ecco i comandi e i passaggi essenziali.

Verifica rapida con dig

Verificare il flag AD (Authenticated Data):

dig +dnssec SOA captaindns.com

Nella sezione flags:, cerca ad. La sua presenza significa che il resolver ha validato la catena DNSSEC con successo. La sua assenza indica che DNSSEC non è implementato oppure che la validazione è fallita.

Verificare i DS record al TLD:

dig DS captaindns.com +short

Questo comando restituisce i DS record pubblicati dal registrar al TLD. Se la risposta è vuota, il tuo dominio non pubblica DNSSEC. Se sono presenti dei DS, verifica che corrispondano alle chiavi attuali della tua zona.

Verificare le chiavi DNSKEY:

dig DNSKEY captaindns.com +short

Devi vedere almeno due chiavi: una con il flag 256 (ZSK) e una con il flag 257 (KSK). L'hash della KSK (flag 257) deve corrispondere al DS record pubblicato al TLD.

Distinguere un problema DNSSEC da un altro problema DNS:

dig captaindns.com +cd

Il flag +cd (Checking Disabled) disattiva la validazione DNSSEC. Se la query funziona con +cd ma fallisce senza (SERVFAIL), il problema è DNSSEC.

Cosa fare se DNSSEC è rotto

Se le tue verifiche rivelano un problema, ecco le azioni correttive in ordine di priorità:

Verificare il DS record presso il registrar. Accedi all'interfaccia del tuo registrar e confronta il DS record pubblicato con la DNSKEY (flag 257) della tua zona. Se hai migrato il fornitore DNS, il DS deve puntare alla KSK del nuovo fornitore.

Verificare i RRSIG nella zona. Le firme hanno una data di scadenza. Se il tuo fornitore DNS ha un problema di ri-firma, i RRSIG possono essere scaduti. Contatta il tuo fornitore DNS o verifica i log di firma se gestisci DNSSEC internamente.

Verificare l'algoritmo. Gli algoritmi RSA-SHA1 e DSA sono deprecati. Prediligi ECDSAP256SHA256 (algoritmo 13) o ECDSAP384SHA384 (algoritmo 14).

Per una diagnostica dettagliata degli errori SERVFAIL legati a DNSSEC, consulta la nostra guida dedicata: risolvere SERVFAIL dopo DNSSEC. Se devi attivare DNSSEC per la prima volta, segui la nostra guida all'attivazione DNSSEC passo dopo passo.

Checklist pre-rinnovo certificato

Prima di ogni rinnovo di certificato su un dominio con DNSSEC:

• Il DS record al registrar corrisponde alla KSK attiva della zona
• I RRSIG non sono scaduti (verificare inception e scadenza con dig +dnssec)
• L'algoritmo utilizzato è supportato (ECDSAP256SHA256 raccomandato)
• Il resolver restituisce il flag AD per il tuo dominio
• Il monitoraggio DNSSEC è attivo e invia avvisi in caso di rottura della catena
• Un dry-run ACME è stato eseguito con successo sul dominio interessato

SC-081 e l'accelerazione dei rinnovi

Il Ballot SC-081, adottato dal CA/Browser Forum, riduce progressivamente la durata massima dei certificati TLS:

Data di applicazione	Durata massima
Marzo 2026	200 giorni
Marzo 2027	100 giorni
Marzo 2029	47 giorni

Questa riduzione ha un impatto diretto sulla criticità di SC-085v2. Più la durata dei certificati è breve, più i rinnovi sono frequenti. E più i rinnovi sono frequenti, più un DNSSEC rotto verrà rilevato rapidamente, ma anche più sarà bloccante.

Con certificati di 200 giorni, un problema DNSSEC che dura una settimana ritarda un rinnovo. Con certificati di 47 giorni, un problema DNSSEC di qualche giorno può provocare la scadenza del certificato prima che il rinnovo riesca. Il margine di errore si riduce drasticamente.

A 47 giorni, l'automazione ACME diventa imprescindibile. Nessuna organizzazione può gestire manualmente rinnovi ogni sei settimane su un parco di domini. E una pipeline ACME automatizzata che fallisce silenziosamente a causa di un DNSSEC rotto è uno scenario di incidente grave.

La raccomandazione è chiara: implementa un monitoraggio DNSSEC continuo su tutti i tuoi domini con certificati TLS. Configura avvisi sulla scadenza dei RRSIG (almeno 7 giorni prima della scadenza) e sulla corrispondenza DS/DNSKEY. Integra la verifica DNSSEC nella tua pipeline di rinnovo ACME, prima della richiesta del certificato.

Piano d'azione: preparare la tua infrastruttura

1. Verificare lo stato DNSSEC di tutti i tuoi domini con il DNSSEC Checker di CaptainDNS
2. Correggere le catene rotte: DS record mancante, firma scaduta, algoritmo incompatibile
3. Auditare i certificati attivi: elencare i domini DNSSEC con certificati da rinnovare nei prossimi 90 giorni
4. Configurare il monitoraggio: avvisi su scadenza RRSIG e scadenza certificato
5. Testare il rinnovo: lanciare un dry-run ACME sui domini DNSSEC
6. Documentare: aggiungere la verifica DNSSEC al tuo runbook di rinnovo

FAQ

Il Ballot SC-085v2 rende DNSSEC obbligatorio per ottenere un certificato TLS?

No. SC-085v2 impone alle CA di validare DNSSEC quando è presente, ma non rende DNSSEC obbligatorio. Se il tuo dominio non pubblica un DS record al TLD, la CA procede con la DCV classica senza validazione DNSSEC. Puoi ottenere un certificato TLS senza DNSSEC, esattamente come prima.

Cosa succede se il mio DNSSEC è rotto durante il rinnovo automatico?

Il rinnovo fallisce. La CA restituisce un errore di tipo dns_sec_validation_error (presso DigiCert) o un SERVFAIL. Il client ACME non può completare la validazione DNS-01 e il certificato non viene rinnovato. Se il problema persiste fino alla scadenza del certificato attuale, il tuo sito diventa inaccessibile in HTTPS. Ecco perché un monitoraggio DNSSEC con avvisi è indispensabile.

Quali CA sono coinvolte da SC-085v2?

Tutte le CA pubblicamente approvate (cioè il cui certificato radice è incluso nei trust store dei browser). Questo include DigiCert, Sectigo, Let's Encrypt, GlobalSign, Entrust, HARICA, SwissSign e tutte le altre CA conformi ai Baseline Requirements del CA/Browser Forum. Le CA private (interne a un'organizzazione) non sono coinvolte.

Let's Encrypt validava già DNSSEC?

Let's Encrypt utilizzava già resolver validanti DNSSEC (Unbound) nella sua infrastruttura. In pratica, un dominio con DNSSEC BOGUS poteva già fallire la validazione presso Let's Encrypt. SC-085v2 formalizza questo requisito nei Baseline Requirements e lo estende a tutte le CA, non solo a quelle che avevano scelto di validare DNSSEC.

Qual è la differenza tra MPIC (SC-067) e SC-085v2?

MPIC (SC-067) protegge la DCV a livello di rete verificando da più punti geografici. Rileva gli attacchi BGP localizzati. SC-085v2 protegge la DCV a livello DNS verificando le firme DNSSEC. Rileva le risposte DNS falsificate. I due sono complementari: MPIC copre il vettore BGP, DNSSEC copre il vettore DNS.

Il mio certificato attuale verrà revocato se DNSSEC si rompe dopo l'emissione?

No. SC-085v2 riguarda unicamente la validazione al momento dell'emissione. Un certificato già emesso resta valido fino alla sua scadenza, anche se DNSSEC si rompe dopo l'emissione. Tuttavia, il prossimo rinnovo fallirà finché DNSSEC è BOGUS.

Come faccio a sapere se il mio dominio pubblica DNSSEC?

Esegui dig DS captaindns.com +short (sostituisci con il tuo dominio). Se il comando restituisce uno o più record DS, il tuo dominio pubblica DNSSEC. Se la risposta è vuota, DNSSEC non è attivato. Puoi anche usare il DNSSEC Checker di CaptainDNS per una diagnostica completa che include la validazione della catena di fiducia.

SC-085v2 riguarda i certificati wildcard?

Sì. I certificati wildcard sono validati tramite DNS-01 (l'unico metodo ACME compatibile con i wildcard). La CA interroga il DNS per verificare il TXT _acme-challenge e applica la validazione DNSSEC su questa query. Se DNSSEC è BOGUS per il tuo dominio, il certificato wildcard non verrà emesso.

Qual è il legame con il Ballot SC-081 sulla riduzione della durata dei certificati?

SC-081 riduce la durata massima dei certificati TLS (200 giorni nel 2026, 100 giorni nel 2027, 47 giorni nel 2029). Certificati più brevi implicano rinnovi più frequenti. Ogni rinnovo attiva una DCV, e ogni DCV include ora la validazione DNSSEC (SC-085v2). Un DNSSEC rotto blocca quindi più spesso il rinnovo, con meno margine prima della scadenza.

Devo attivare DNSSEC per beneficiare della protezione SC-085v2?

Sì. SC-085v2 protegge unicamente i domini che pubblicano DNSSEC. Senza DNSSEC, la CA non può verificare l'autenticità delle risposte DNS e la DCV resta vulnerabile allo spoofing. Attivare DNSSEC sul tuo dominio è l'unico modo per beneficiare di questa protezione rafforzata durante l'emissione dei certificati.

Glossario

• CA (Certificate Authority): autorità di certificazione abilitata a emettere certificati TLS. Le CA pubbliche sono incluse nei trust store dei browser e soggette ai Baseline Requirements del CA/Browser Forum.
• DCV (Domain Control Validation): processo con cui una CA verifica che il richiedente di un certificato controlla effettivamente il dominio. Metodi comuni: DNS-01, HTTP-01, email.
• CA/Browser Forum: consorzio che raggruppa le CA e gli editori di browser. Definisce i Baseline Requirements, il quadro normativo che tutte le CA pubbliche devono rispettare.
• MPIC (Multi-Perspective Issuance Corroboration): meccanismo imposto dal Ballot SC-067, che obbliga le CA a validare la DCV da almeno due prospettive di rete geograficamente distanti per contrastare il BGP hijacking.
• BOGUS: stato interno del resolver DNSSEC quando la validazione crittografica fallisce. Un dominio BOGUS provoca un SERVFAIL per il client. Dopo SC-085v2, un dominio BOGUS blocca anche l'emissione dei certificati.
• ACME (Automatic Certificate Management Environment): protocollo standardizzato (RFC 8555) per l'automazione dell'emissione e del rinnovo dei certificati TLS. Utilizzato da Let's Encrypt, certbot, acme.sh e cert-manager.
• Baseline Requirements (BR): documento normativo del CA/Browser Forum che definisce i requisiti minimi per l'emissione di certificati TLS da parte delle CA pubbliche. SC-085v2 modifica i BR per imporre la validazione DNSSEC.

Fonti

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)