Il CA/Browser Forum ha votato per rendere obbligatorie le estensioni ACME CAA a partire da marzo 2027. Questo cambiamento rappresenta uno degli ultimi tasselli necessari per supportare una convalida del dominio solida e crittograficamente verificata nella Web PKI. In questo articolo del blog, discutiamo perché la Web PKI non fornisce garanzie sufficienti per i siti web di alto profilo e come DNSSEC, ACME e CAA possano essere combinati per ottenere una robusta convalida crittografica dell'emissione dei certificati.
Convergenza tra DNSSEC e Web PKI
Non a tutti piace DNSSEC, ma fornisce funzionalità di sicurezza importanti che non possiamo ottenere altrove. Le aziende che lo abilitano sui propri nomi di dominio ottengono l'integrità della risoluzione DNS. Alcuni sostengono che la Web PKI funzioni perfettamente, ed è vero, ma solo per il caso d'uso comune: proteggere siti web che non sono soggetti a minacce serie. In sintesi, i siti web di alto profilo hanno bisogno di una sicurezza migliore.
Per molto tempo, i sostenitori di DNSSEC hanno affermato che avrebbe potuto sostituire la Web PKI. Il loro ragionamento era che, una volta ottenuta l'integrità della risoluzione DNS, si ottiene una proprietà di sicurezza su cui costruire per far funzionare i certificati X.509 senza le CA. Questo è vero, ma solo in teoria. In pratica, DNSSEC presenta una serie di problemi di progettazione e operativi che ne rendono difficile l'adozione su larga scala. Di conseguenza, dopo molti anni, il suo supporto è ancora lontano dal livello necessario. La Web PKI e le CA sono destinate a rimanere.
Tuttavia, le organizzazioni che necessitano di una sicurezza X.509 pubblica robusta non hanno altra scelta che implementare DNSSEC per le sue funzionalità uniche.
Nel 2025, il CA/Browser Forum, l'organismo che regola l'emissione dei certificati, ha deciso di incorporare la convalida DNSSEC nel processo di convalida del dominio. Il requisito è diventato obbligatorio a marzo 2026 e, per la prima volta, ha reso possibile una robusta convalida crittografica dell'emissione dei certificati.
Punti deboli alla base della Web PKI
La Web PKI è la PKI pubblica gestita in modo più rigoroso, con regole e controlli elaborati. È un ecosistema che abbiamo trascorso decenni a migliorare. Tuttavia, al suo interno presenta due problemi significativi. Questi rendono il sistema più facile da usare, ma paghiamo questo vantaggio con requisiti di sicurezza più permissivi.
In primo luogo, non esiste alcuna autenticazione di chi richiede il certificato. Chiunque al mondo può richiedere un certificato per qualsiasi nome di dominio; se il processo di convalida ha successo, il certificato verrà emesso al richiedente, anche se il proprietario del dominio non lo ha autorizzato.
In secondo luogo, quando viene richiesto un certificato, la CA esegue la convalida del dominio attraverso BGP, DNS e traffico di rete non protetti. Chiunque possa interferire con uno di questi tre elementi può compromettere la convalida del dominio.
Se aggiungiamo DNSSEC a questo mix, ciò contribuisce a proteggere il DNS, ma i restanti due aspetti (BGP e traffico di rete in chiaro) rimangono insicuri. Dobbiamo riuscire in un'impresa particolare: prendere le decisioni chiave tramite DNSSEC e impedire l'uso di qualsiasi altro metodo.
Certification Authority Authorization
I punti deboli della Web PKI possono essere affrontati utilizzando uno standard chiamato Certification Authority Authorization (CAA), definito nell'RFC 8659. CAA è progettato per consentire ai proprietari di domini di pubblicare le proprie politiche di emissione dei certificati.
La versione base di CAA è obbligatoria dal settembre 2017, ma non è sufficiente per le nostre esigenze. Esiste un altro documento (RFC 8657) che fa da ponte tra il protocollo ACME per l'emissione automatizzata dei certificati e CAA, aggiungendo il supporto per permessi granulari.
Con le estensioni ACME CAA, possiamo risolvere entrambi i problemi descritti in precedenza, grazie a un singolo record di risorsa CAA nel nostro DNS che appare più o meno così:
example.com. CAA 0 issue "letsencrypt.org;
accounturi=https://acme-v02.api.
letsencrypt.org/acme/acct/1726001367;
validationmethods=dns-01"Cosa fa questo record?
A sinistra vediamo il nome di dominio per il quale vogliamo controllare l'emissione dei certificati, in questo caso example.com. A destra abbiamo tre controlli. Il primo è l'identità di una CA autorizzata a emettere certificati per il nome di dominio, in questo caso letsencrypt.org.
Il secondo controllo è l'istruzione accounturi, che blocca l'emissione esclusivamente all'account ACME indicato. Poiché ACME utilizza sempre la crittografia e un'autenticazione crittografica robusta per gli account ACME, questa sezione garantisce che solo gli utenti autorizzati possano richiedere certificati per questo nome di dominio.
Il terzo controllo è l'istruzione validationmethods, che blocca l'emissione all'uso di un unico metodo di convalida del dominio basato su DNS. Quando DNSSEC è abilitato per un nome di dominio, questa sezione garantisce che tutte le operazioni di convalida del dominio siano crittograficamente sicure. Con questo, non dobbiamo più preoccuparci di altri metodi insicuri; la CA non li accetterà mai, in primo luogo.
Possiamo usare le estensioni ACME CAA già ora?
Le estensioni ACME CAA esistono dal 2019, e alcune CA (ad esempio, Let's Encrypt, Google Trust Services e altre) le supportano già. Quindi, in teoria, avreste potuto disporre di controlli di emissione più solidi già da marzo 2026, quando DNSSEC è diventato obbligatorio per la convalida del dominio. In pratica, finché una funzionalità non viene inserita nei Baseline Requirements, le CA sono sempre riluttanti a impegnarsi pienamente. Questo perché ogni nuova funzionalità aumenta il loro carico di lavoro e rende il loro compito più complesso. Il mancato rispetto di una politica scritta potrebbe comunque portare all'emissione del certificato.
Il team di Chrome è da tempo un sostenitore dell'automazione. Il supporto per l'automazione è stato un elemento centrale della loro Root Program Policy e, al suo interno, dei requisiti per ACME e per le estensioni ACME CAA. Nel febbraio 2026, la policy è stata modificata per richiedere il supporto di ACME CAA a tutte le CA che supportano ACME.
Nel maggio 2026, il CA/Browser Forum ha votato (nella Ballot SC-098v2) per estendere formalmente il supporto a CAA e rendere obbligatorie le estensioni ACME CAA (RFC 8657) per tutte le CA, a partire da marzo 2027.
Potete utilizzare le estensioni ACME CAA già oggi, se lavorate con CA che le supportano. A partire dal prossimo anno, questa funzionalità sarà ampiamente supportata e avrete la possibilità di scegliere tra diverse CA con cui lavorare.
Ivan Ristic is the Chief Scientist for Red Sift and former founder of Hardenize. Learn more about how Red Sift helps organizations with their Certificate Monitoring.