Record DNS CAA: la guida completa per controllare chi emette i tuoi certificati
Di CaptainDNS
Pubblicato il 9 giugno 2026
- Un record DNS CAA dichiara quali autorità di certificazione hanno il diritto di emettere un certificato TLS per il tuo dominio. Senza CAA, qualsiasi CA pubblica può farlo.
- La sintassi sta in tre campi:
flag tag value. I tag utili sonoissue(certificati classici),issuewild(wildcard) eiodef(segnalazione dei tentativi non autorizzati). - La CA verifica il CAA al momento dell'emissione risalendo il DNS dal sottodominio verso l'apex (tree climbing), e si ferma al primo record trovato (RFC 8659).
- La RFC 8657 aggiunge
accounturievalidationmethodsper vincolare l'emissione a un account ACME preciso e a metodi di validazione autorizzati. - Una configurazione CAA mal pensata (issuewild dimenticato, punto e virgola frainteso, CA assente) può bloccare i tuoi rinnovi ACME automatici.
Il modello di fiducia dei certificati TLS si basa su un centinaio di autorità di certificazione (CA) riconosciute dai browser. Il problema è strutturale: per impostazione predefinita, una qualsiasi di queste CA può emettere un certificato valido per il tuo dominio, senza il tuo consenso e senza nemmeno avvisarti. Un attaccante che riesce a ingannare una sola CA, o una CA che commette un errore, può produrre un certificato perfettamente riconosciuto per captaindns.com.
Il record DNS CAA (Certificate Authority Authorization), definito dalla RFC 8659, chiude in parte questa porta. Agisce come un'allowlist pubblicata nella tua zona DNS: prima di emettere un certificato, una CA conforme deve interrogare il DNS e verificare di figurare effettivamente nei tuoi record CAA. Se non c'è, rifiuta di emettere. È una barriera all'emissione, non un rilevamento a posteriori.
Questa guida si rivolge agli amministratori di sistema, ai team DevOps e SRE, e ai responsabili della sicurezza. Copre il modello di minaccia, la sintassi completa di un record CAA (tag issue, issuewild, iodef, flag critico), il meccanismo esatto di validazione tramite risalita dell'albero, i parametri avanzati della RFC 8657 per l'ecosistema ACME, la configurazione concreta presso i principali provider e gli errori che rompono i rinnovi automatici.
I tuoi record CAA e DNSSEC sono configurati correttamente?
Il problema: qualsiasi CA può emettere un certificato
Quando il tuo browser apre una connessione HTTPS, verifica che il certificato presentato sia firmato da un'autorità di certificazione presente nel suo store di fiducia. Questo store contiene un centinaio di CA radice, gestite da organizzazioni molto diverse, distribuite in numerosi paesi.
Una fiducia orizzontale e senza compartimentazione
Il difetto di progettazione è semplice da enunciare: la fiducia è orizzontale. Il browser si fida di tutte le CA del suo store in modo equivalente. Niente, nel protocollo di base, limita una data CA a un sottoinsieme di domini. In concreto, una CA situata dall'altra parte del mondo, che non hai mai usato, è tecnicamente abilitata a emettere un certificato riconosciuto per il tuo dominio.
Finché tutte le CA funzionano perfettamente, questo modello regge. Ma basta che una sola fallisca, per errore operativo o compromissione, perché venga prodotto un certificato fraudolento e accettato da tutti i browser.
Incidenti ben reali
La storia dei certificati TLS è costellata di incidenti di emissione errata (mis-issuance):
- DigiNotar (2011): questa CA olandese è stata compromessa. Gli attaccanti hanno emesso oltre 500 certificati fraudolenti, tra cui un wildcard per
*.google.com, usato per intercettare il traffico di cittadini iraniani. DigiNotar ha perso la fiducia dei browser ed è fallita. - Symantec (dal 2015 al 2017): una serie di emissioni non conformi, tra cui certificati di test per domini di terzi emessi senza autorizzazione, ha portato Google e Mozilla a programmare la revoca della fiducia accordata alla vecchia infrastruttura Symantec. L'attività di CA è stata ceduta a DigiCert.
- BGP hijacking: diversi attacchi hanno combinato dirottamento di route di rete e validazione di dominio per ottenere certificati fraudolenti. Il caso MyEtherWallet (2018) ha visto degli attaccanti dirottare il traffico DNS per ottenere un certificato e rubare fondi.
Questi incidenti condividono un punto in comune: un certificato tecnicamente valido è stato emesso per un dominio senza il consenso del suo proprietario. La ricerca accademica ha confermato che questo rischio non è affatto aneddotico. Lo studio "Bamboozling Certificate Authorities with BGP" (USENIX Security 2018) ha dimostrato che un attaccante poteva ottenere certificati fraudolenti dalle più grandi CA dirottando le query di validazione di dominio via BGP, con un tasso di successo elevato.
La lezione è che una sola falla in una qualsiasi delle CA di fiducia basta a compromettere un qualsiasi dominio. È precisamente l'ampiezza di questa superficie di attacco che il CAA viene a ridurre, limitando l'elenco delle CA abilitate a emettere per un dato dominio.
Il rilevamento non basta
La Certificate Transparency (CT) impone dal 2018 che ogni certificato pubblico sia registrato in log pubblici e verificabili. È un progresso importante: un proprietario di dominio può monitorare questi log e individuare un certificato emesso a sua insaputa.
Ma la Certificate Transparency è un meccanismo di rilevamento a posteriori. Nel momento in cui individui un certificato fraudolento in un log, esso è già stato emesso e può già essere stato usato. Il CAA affronta il problema a monte: impedisce l'emissione invece di constatarla a posteriori. I due meccanismi sono complementari, come spieghiamo più avanti.
Che cos'è un record CAA?
Un record DNS CAA (Certificate Authority Authorization, RFC 8659) indica quali autorità di certificazione sono autorizzate a emettere certificati TLS per un dominio. Prima di ogni emissione, la CA interroga il DNS del dominio e rifiuta di emettere se non figura nell'elenco pubblicato. È un'autorizzazione preventiva, controllata dal proprietario del dominio tramite la sua zona DNS.
Un tipo di record DNS dedicato
Il CAA è un tipo di record DNS a sé stante, il tipo 257. Si pubblica nella tua zona esattamente come un record A, MX o TXT. Puoi collocarlo all'apex della zona (captaindns.com) o su un sottodominio preciso (api.captaindns.com).
Ecco un esempio minimo che autorizza solo Let's Encrypt a emettere certificati per il dominio:
captaindns.com. IN CAA 0 issue "letsencrypt.org"
Questo record dichiara una sola cosa: l'unica CA autorizzata a emettere un certificato per captaindns.com è Let's Encrypt, identificata dal suo dominio letsencrypt.org. Qualsiasi altra CA conforme che riceve una richiesta per questo dominio la rifiuterà.
Un punto essenziale sulla semantica: la presenza di un solo record issue trasforma la policy implicita. Senza CAA, tutte le CA sono autorizzate per impostazione predefinita. Non appena esiste un issue, il comportamento di default si inverte: solo le CA esplicitamente elencate sono autorizzate, tutte le altre sono implicitamente vietate. Aggiungere una CA alla tua policy consiste quindi nel pubblicare un record issue aggiuntivo; dimenticarne una equivale a bloccarla.
Una storia in due RFC
Il CAA è stato definito inizialmente dalla RFC 6844 nel 2013. Questa prima versione comportava un meccanismo di risalita dell'albero (tree climbing) ritenuto ambiguo, in particolare sulla gestione degli errori e degli alias CNAME/DNAME.
La RFC 8659, pubblicata nel 2019, sostituisce la RFC 6844 e costituisce il riferimento attuale. Chiarisce l'algoritmo di risalita e corregge le zone d'ombra della prima versione. Una RFC complementare, la RFC 8657 (2019), aggiunge due parametri orientati ad ACME: accounturi e validationmethods. Trattiamo questi parametri in una sezione dedicata.
Una barriera, non una garanzia assoluta
Il CAA si basa sulla cooperazione delle CA. Tutte le CA pubblicamente riconosciute, soggette ai Baseline Requirements del CA/Browser Forum, sono obbligate a verificare il CAA prima dell'emissione. È un requisito del framework, non un'opzione. In pratica, le CA principali applicano questa verifica.
Il CAA non protegge quindi contro una CA disonesta che scelga di ignorare deliberatamente i tuoi record, né contro una CA privata interna a un'organizzazione. Ma alza notevolmente la barriera: per emettere un certificato fraudolento nonostante un CAA ben configurato, un attaccante dovrebbe compromettere la CA che hai esplicitamente autorizzato, oppure falsificare le tue risposte DNS al momento del controllo. Quest'ultimo punto ci porta al legame tra CAA e DNSSEC, affrontato più avanti.
Anatomia di un record CAA
Un record CAA sta in tre campi, sempre nello stesso ordine. Padroneggiare questa sintassi è indispensabile per non sbagliare configurazione.
La struttura flag tag value
Ogni record CAA si compone di tre elementi:
| Campo | Ruolo | Valori |
|---|---|---|
flag | Intero di controllo | 0 (non critico) o 128 (critico) |
tag | Proprietà interessata | issue, issuewild o iodef |
value | Valore della proprietà | Identificativo della CA, o URL di segnalazione |
Letto da sinistra a destra, il record 0 issue "letsencrypt.org" si traduce in: flag non critico, proprietà issue, valore letsencrypt.org. Il valore è sempre tra virgolette dritte nella rappresentazione testuale.
Il tag issue: autorizzare una CA per i certificati classici
Il tag issue autorizza una CA a emettere certificati non wildcard per il dominio. Il valore è l'identificativo della CA, generalmente un nome di dominio.
captaindns.com. IN CAA 0 issue "letsencrypt.org"
captaindns.com. IN CAA 0 issue "digicert.com"
Questo esempio autorizza due CA: Let's Encrypt e DigiCert. Quando più record issue coesistono, si sommano: ogni CA elencata è autorizzata. È un'allowlist cumulativa.
Un caso particolare merita attenzione: il valore ";" (un semplice punto e virgola). Vieta qualsiasi emissione.
captaindns.com. IN CAA 0 issue ";"
Questo record dichiara che nessuna CA è autorizzata a emettere un certificato classico per il dominio. È utile per un dominio che non deve mai avere un certificato (un dominio in parcheggio, ad esempio), ma è anche una fonte di errore frequente quando viene impostato per disattenzione.
Il tag issuewild: il caso dei wildcard
Il tag issuewild controlla specificamente l'emissione dei certificati wildcard (del tipo *.captaindns.com). La sua sintassi è identica a quella di issue.
La regola di priorità è essenziale: issuewild prevale su issue per i certificati wildcard. Se è presente un record issuewild, è quello a fare fede per le richieste wildcard, e i record issue vengono ignorati per questo caso. Se nessun issuewild è presente, i certificati wildcard ricadono sulle regole issue.
captaindns.com. IN CAA 0 issue "letsencrypt.org"
captaindns.com. IN CAA 0 issuewild "digicert.com"
In questo esempio, i certificati classici possono essere emessi solo da Let's Encrypt, mentre i certificati wildcard possono esserlo solo da DigiCert. Per vietare puramente e semplicemente qualsiasi certificato wildcard, si usa il punto e virgola:
captaindns.com. IN CAA 0 issuewild ";"
Questo blocca qualsiasi emissione di wildcard lasciando comunque che i certificati classici seguano le regole issue.
Il tag iodef: segnalare i tentativi non autorizzati
Il tag iodef (Incident Object Description Exchange Format) indica dove una CA deve segnalare una richiesta di certificato che viola la tua policy CAA. Il valore è un URL, sia un'email in formato mailto:, sia un URL HTTPS.
captaindns.com. IN CAA 0 iodef "mailto:security@captaindns.com"
captaindns.com. IN CAA 0 iodef "https://captaindns.com/caa-report"
Quando una CA riceve una richiesta che rifiuta a causa del tuo CAA, può inviare un report all'indirizzo iodef. È un segnale prezioso: un tentativo di emissione non autorizzato può indicare un attacco in corso o un servizio interno mal configurato. Il supporto di iodef varia a seconda delle CA; va considerato come un bonus di visibilità, non come una garanzia di notifica.
In pratica, un report iodef merita un'indagine immediata. O uno dei tuoi servizi tenta di emettere un certificato tramite una CA che hai dimenticato di autorizzare (problema di configurazione), oppure un attore esterno tenta di ottenere un certificato per il tuo dominio (problema di sicurezza). In entrambi i casi, l'iodef ti dà una visibilità che né la Certificate Transparency né i log della tua infrastruttura forniscono, perché coglie il tentativo nel momento preciso del rifiuto.
Il flag critico: 0 contro 128
Il primo campo, il flag, è un byte di cui solo il bit più significativo (valore 128, ovvero 0x80) ha un significato definito: è il flag critico (issuer critical).
- Flag 0: record non critico. Se una CA non comprende il tag, lo ignora e prosegue.
- Flag 128: record critico. Se una CA incontra un tag che non comprende con questo flag impostato, deve rifiutare di emettere.
Il flag critico serve a tutelarsi contro l'introduzione futura di tag che le vecchie CA non saprebbero interpretare. Impostando il flag 128 su un tag, esigi che ogni CA che non lo comprende si astenga, per sicurezza, invece di ignorarlo. Nella stragrande maggioranza delle configurazioni, il flag resta a 0: i tag issue, issuewild e iodef sono universalmente compresi.
Gli identificativi delle CA più comuni
Il valore di un tag issue o issuewild è l'identificativo della CA, definito da ciascuna autorità nella propria documentazione. Ecco gli identificativi delle principali CA:
| Autorità di certificazione | Identificativo CAA |
|---|---|
| Let's Encrypt | letsencrypt.org |
| DigiCert | digicert.com |
| Sectigo | sectigo.com |
| GlobalSign | globalsign.com |
| Google Trust Services | pki.goog |
| Amazon (AWS Certificate Manager) | amazon.com (e amazontrust.com, amazonaws.com, awstrust.com) |
Usa sempre l'identificativo esatto pubblicato dalla CA, e non un'approssimazione. Un valore errato equivale a non autorizzare la CA, e il certificato verrà rifiutato. In caso di dubbio sull'identificativo di una CA non elencata qui, consulta la sua documentazione ufficiale invece di tirare a indovinare.
Come funziona la validazione CAA
La forza del CAA risiede nel suo meccanismo di validazione al momento dell'emissione. Comprendere questo meccanismo evita la maggior parte degli errori di configurazione.
La risalita dell'albero (tree climbing)
Quando una CA elabora una richiesta di certificato per un dato nome, non si limita a guardare il CAA di quel nome preciso. Risale la gerarchia DNS, label dopo label, dal nome richiesto verso l'apex della zona, finché non trova un insieme di record CAA. È il tree climbing, definito alla sezione 3 della RFC 8659.
Prendiamo una richiesta per api.captaindns.com. La CA procede così:
- Interroga il CAA di
api.captaindns.com. Se vi è pubblicato un insieme CAA, lo usa e si ferma. - Altrimenti, risale di un livello e interroga
captaindns.com. Se vi è pubblicato un insieme CAA, lo usa e si ferma. - La risalita prosegue finché non trova un insieme CAA, o finché non raggiunge la radice senza trovare nulla.
Il punto chiave: la CA si ferma al primo nome che possiede record CAA. I record dei livelli superiori non vengono allora consultati.
L'ereditarietà e le sue conseguenze
Questo meccanismo ha una conseguenza importante: un sottodominio eredita la policy CAA del suo genitore, ma solo se non definisce la propria.
Se pubblichi un CAA all'apex captaindns.com e niente su api.captaindns.com, allora api.captaindns.com è soggetto alla policy dell'apex. Ma non appena pubblichi un solo record CAA su api.captaindns.com, la CA si ferma a quel livello e ignora completamente l'apex. L'ereditarietà è binaria: o il sottodominio non ha alcun CAA ed eredita, oppure ne ha uno e sostituisce integralmente la policy del genitore. Non c'è alcuna fusione tra i due livelli.
È una fonte di errore classica: si aggiunge un CAA specifico su un sottodominio per autorizzare una CA aggiuntiva, senza rendersi conto che questo record sostituisce la policy dell'apex invece di sommarsi a essa. Il sottodominio deve allora elencare tutte le CA di cui ha bisogno, comprese quelle già autorizzate a livello del genitore.
L'interazione con i wildcard
Il caso dei certificati wildcard combina due regole. Innanzitutto la priorità issuewild su issue vista sopra. Poi la risalita dell'albero. Per una richiesta di *.captaindns.com, la CA cerca prima un insieme CAA risalendo l'albero, poi applica all'interno di questo insieme la priorità issuewild. Se l'insieme trovato contiene un issuewild, è quello a fare fede per il wildcard; altrimenti, il wildcard ricade sugli issue dello stesso insieme.
Il caso degli alias CNAME
Quando il nome elaborato per la validazione CAA punta a un alias CNAME, la ricerca CAA segue questo alias. La RFC 8659 precisa che se un nome è un alias CNAME, la ricerca CAA prosegue sulla destinazione dell'alias. È un dettaglio che a volte sorprende: un sottodominio in CNAME verso un servizio di terzi può, a seconda della configurazione, dipendere dal CAA della destinazione invece che da quello della tua zona. Quando deleghi un sottodominio a un provider esterno tramite CNAME, verifica quale policy CAA si applica realmente.
Cosa verifica realmente la CA all'emissione
Al momento di emettere, una CA conforme ai Baseline Requirements effettua il controllo CAA in una finestra temporale limitata (al massimo 8 ore prima dell'emissione, secondo il framework). Trascorso questo termine, il controllo deve essere rifatto. Questo vincolo evita che un'autorizzazione ottenuta molto in anticipo resti valida dopo che hai rimosso una CA dalla tua policy.
La CA deve anche, dall'introduzione della validazione multi-prospettiva (MPIC, Ballot SC-067), effettuare il controllo CAA e la validazione di dominio da più punti di presenza di rete geograficamente distinti. L'obiettivo è contrastare i dirottamenti BGP localizzati: se un attaccante dirotta il traffico in una regione per falsificare la risposta CAA, le altre prospettive riceveranno la risposta legittima e la CA rileverà l'incoerenza. MPIC protegge quindi il controllo CAA a livello di rete, mentre DNSSEC lo protegge a livello del protocollo DNS. I due meccanismi si rafforzano a vicenda.
In concreto, la sequenza di emissione assomiglia a questa: la CA riceve la richiesta, valida il controllo di dominio (DNS-01, HTTP-01 o TLS-ALPN-01), interroga il CAA risalendo l'albero, conferma di figurare nell'elenco autorizzato, poi emette. Se il CAA la rifiuta, l'emissione si arresta immediatamente e, se è presente un iodef, può essere inviato un report.
Il legame con DNSSEC
Il controllo CAA si basa su risposte DNS. Se un attaccante può falsificare le tue risposte DNS nel momento in cui la CA interroga il CAA, può ingannare il controllo. DNSSEC risponde a questo rischio autenticando crittograficamente le risposte DNS.
Il CA/Browser Forum ha formalizzato questo legame con il Ballot SC-085v2, in vigore dal 15 marzo 2026, che impone alle CA di validare DNSSEC, quando è presente, durante le query CAA e di validazione di dominio. In concreto, se la tua zona è firmata e la catena di fiducia è intatta, la CA ottiene la garanzia che i record CAA che legge sono autentici. Abbiamo dedicato un articolo completo a questo cambiamento normativo: le CA verificano ora DNSSEC prima di emettere un certificato. Puoi controllare lo stato di firma della tua zona con il nostro verificatore DNSSEC. Per attivare DNSSEC su un dominio che non ne beneficia ancora, segui la nostra guida all'attivazione passo dopo passo.
Parametri avanzati: la RFC 8657 e ACME
La RFC 8657 estende il CAA con due parametri che si inseriscono nel tag issue o issuewild. Sono particolarmente utili in un ecosistema ACME automatizzato.
accounturi: vincolare un account ACME
Il parametro accounturi limita l'emissione a un account ACME preciso. Invece di autorizzare un qualsiasi account di una data CA a emettere per il tuo dominio, vincoli l'autorizzazione all'URI di un singolo account ACME.
captaindns.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678"
Questo record autorizza Let's Encrypt a emettere, ma unicamente per l'account ACME numerato 12345678. Una richiesta proveniente da un altro account Let's Encrypt sarà rifiutata. È una protezione forte: anche se un attaccante usa la stessa CA che usi tu, non potrà emettere con il proprio account.
validationmethods: limitare i metodi di validazione
Il parametro validationmethods limita i metodi di validazione ACME autorizzati per il dominio. I valori corrispondono ai tipi di challenge ACME: dns-01, http-01 e tls-alpn-01.
captaindns.com. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01"
Qui, è accettata solo la validazione tramite record DNS (dns-01). Un tentativo di emissione via http-01 (posizionamento di un file sul server web) sarà rifiutato. Questo irrigidisce la configurazione: se sai che i tuoi certificati sono sempre validati tramite dns-01, vietare gli altri metodi riduce la superficie di attacco, ad esempio un server web compromesso che tentasse una validazione http-01.
I tre metodi di validazione ACME hanno profili di rischio distinti. Il metodo dns-01 richiede il controllo della zona DNS e permette i certificati wildcard. Il metodo http-01 richiede il controllo del server web sulla porta 80. Il metodo tls-alpn-01 valida tramite un'estensione TLS sulla porta 443. Limitare validationmethods al solo metodo che usi realmente impedisce a un attaccante che controllasse solo uno di questi vettori di ottenere un certificato per una via che non avevi previsto.
Combinare i parametri per un dominio rafforzato
I parametri si cumulano in uno stesso record, separati da punti e virgola. Una configurazione rafforzata tipica combina CA, account e metodo:
captaindns.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678; validationmethods=dns-01"
Questo record autorizza solo Let's Encrypt, unicamente tramite l'account ACME 12345678, e unicamente con il metodo dns-01. È il livello di controllo più fine offerto dal CAA. Attenzione tuttavia: più la configurazione è rigida, più un errore (cambio di account, migrazione del metodo di validazione) rischia di bloccare un rinnovo. Il supporto della RFC 8657 dipende anche dalla CA; Let's Encrypt lo implementa, ma verifica la documentazione della tua CA prima di distribuire accounturi o validationmethods.
Guida pratica: configurare CAA presso il tuo provider
La sintassi CAA è standard, ma ogni provider DNS espone un'interfaccia diversa. Alcuni richiedono i tre campi separatamente (flag, tag, value), altri una stringa completa. Il tipo di record è sempre CAA (tipo 257). Ecco i passaggi presso i provider più comuni.
Cloudflare
Nella dashboard di Cloudflare, vai su DNS poi Records, e aggiungi un record di tipo CAA. L'interfaccia presenta tre campi distinti:
- Flags: lascia 0 nella maggior parte dei casi.
- Tag: scegli
issue,issuewildoiodefdal menu a tendina. - CA domain name (o Value): inserisci l'identificativo, ad esempio
letsencrypt.org.
Cloudflare offre anche un'API e il suo strumento da riga di comando per automatizzare la creazione di record CAA in un'infrastruttura as code. Nota che Cloudflare a volte aggiunge automaticamente record CAA per i propri certificati gestiti; verifica l'elenco completo dopo la modifica per non sovrascrivere una voce necessaria a un servizio Cloudflare.
AWS Route 53
Nella console Route 53, seleziona la tua zona ospitata e crea un record di tipo CAA. Route 53 si aspetta il valore in formato completo, una riga per record:
0 issue "amazon.com"
0 issue "letsencrypt.org"
Se i tuoi certificati sono gestiti da AWS Certificate Manager (ACM), Amazon documenta diversi identificativi accettati: amazon.com, amazontrust.com, amazonaws.com e awstrust.com. Puoi autorizzarli tutti per coprire l'insieme dei casi. Ricorda di conservare le altre CA di cui hai bisogno per i servizi al di fuori di AWS.
OVHcloud
Nello spazio cliente OVHcloud, apri la zona DNS del tuo dominio e aggiungi una voce. Seleziona il tipo CAA. OVHcloud chiede generalmente il flag, il tag e la destinazione (il valore) in campi distinti. Inserisci 0 per il flag, il tag desiderato e l'identificativo della CA per la destinazione. Conferma, poi attendi la propagazione.
Gandi
Nell'interfaccia di gestione DNS di Gandi (LiveDNS), aggiungi un record di tipo CAA. Gandi si aspetta il valore in formato testuale completo:
0 issue "letsencrypt.org"
Come presso gli altri provider, puoi aggiungere più righe CAA per autorizzare più CA, o per aggiungere issuewild e iodef. La validazione dei certificati Gandi per i domini ospitati presso di loro si basa sulle CA che utilizzano; ricorda di includerle se conti sui loro certificati.
Verificare la propagazione dopo la configurazione
Qualunque sia il provider, non considerare la configurazione terminata finché non hai confermato che il record è visibile pubblicamente. Interroga il DNS dall'esterno della tua rete e conferma che il CAA appaia effettivamente con il flag, il tag e il valore attesi. Tieni conto del TTL: un record modificato può restare in cache per la durata del TTL precedente. Su un dominio firmato con DNSSEC, verifica anche che il nuovo record CAA sia firmato correttamente, altrimenti un resolver validante lo rifiuterà.
Configurare iodef per la segnalazione
Qualunque sia il provider, il tag iodef si configura come issue, ma il suo valore è un URL di segnalazione invece di un identificativo di CA. Usa un indirizzo email monitorato dal tuo team di sicurezza:
0 iodef "mailto:security@captaindns.com"
Verifica che l'indirizzo sia effettivamente controllato. Un iodef che punta a una casella abbandonata non serve a nulla.
Testare prima di bloccare
Una raccomandazione prudente: inizia con una policy permissiva che elenchi tutte le CA che usi realmente, distribuiscila, verifica che i rinnovi passino, poi irrigidisci progressivamente. Tieni conto del TTL dei tuoi record: un TTL elevato rallenta il recepimento di un cambio di CA. Prima di una migrazione di CA, abbassa il TTL del CAA per accelerare la propagazione.
Verificare e auditare i tuoi record CAA
Una volta distribuito il CAA, verifica che sia pubblicato correttamente e che rifletta la tua intenzione. Due approcci si completano a vicenda: la riga di comando e gli strumenti di audit.
Leggere il CAA con dig
Lo strumento dig interroga direttamente il DNS. Per visualizzare i record CAA di un dominio:
dig CAA captaindns.com +short
L'output assomiglia a questo:
0 issue "letsencrypt.org"
0 issuewild "digicert.com"
0 iodef "mailto:security@captaindns.com"
Ogni riga corrisponde a un record CAA, nell'ordine flag tag value. Se il comando non restituisce nulla, il dominio non pubblica alcun CAA a questo livello. Non dimenticare la risalita dell'albero: un sottodominio senza CAA eredita dall'apex. Per verificare cosa eredita realmente api.captaindns.com, interroga in successione il sottodominio e poi l'apex.
Per vedere il dettaglio completo, compresi il TTL e la sezione di autorità, ometti l'opzione +short:
dig CAA captaindns.com
Gli strumenti CaptainDNS
La riga di comando mostra il record grezzo, ma non dice se è coerente. CaptainDNS offre due livelli di verifica.
Il verificatore CAA dedicato mostra i tuoi record e la loro interpretazione, tenendo conto dell'ereditarietà tramite risalita dell'albero. Ti indica chiaramente quale CA è autorizzata per i certificati classici e per i wildcard.
Per una visione più ampia, il nostro audit di sicurezza e deliverability integra ora il CAA nel suo scoring. Il pilastro Sicurezza DNS combina due segnali: DNSSEC, che pesa 80 punti, e CAA, che pesa 20 punti. Questa ponderazione riflette il loro rispettivo ruolo: DNSSEC autentica l'insieme delle tue risposte DNS, il CAA limita specificamente l'emissione di certificati. Un dominio che pubblica un CAA coerente guadagna questi 20 punti e migliora la sua postura di sicurezza complessiva.
Cosa controllare
Durante l'audit, controlla alcuni punti precisi:
- Coerenza issue e issuewild: la CA che emette i tuoi wildcard è effettivamente autorizzata da un
issuewild, oppure conti sul ripiego suissue? - Nessuna CA orfana: ogni CA che usi realmente (compresi i servizi di terzi, CDN, gateway mail) figura nell'elenco?
- iodef raggiungibile: l'indirizzo di segnalazione è monitorato?
- Nessun punto e virgola involontario: un
issue ";"impostato per errore bloccherebbe qualsiasi emissione.
Errori comuni da evitare
La maggior parte degli incidenti legati al CAA deriva da alcuni errori ricorrenti. Conoscerli permette di anticiparli.
Dimenticare issuewild. Pubblichi un issue per Let's Encrypt e tutto funziona, fino al giorno in cui richiedi un certificato wildcard. Se nessun issuewild è presente, il wildcard ricade su issue, e passa. Ma se hai impostato un issuewild per un'altra CA, o un issuewild ";", il wildcard sarà rifiutato. Verifica sempre la coerenza tra issue e issuewild.
Bloccare la propria CA. L'errore più diretto: dimenticare di elencare la CA che usi realmente. Se i tuoi certificati provengono da Let's Encrypt ma il tuo CAA autorizza solo DigiCert, il prossimo rinnovo fallirà. Questo errore si verifica spesso dopo un cambio di CA o l'aggiunta di un nuovo servizio.
Rompere il rinnovo ACME con una policy troppo rigida. I parametri accounturi e validationmethods sono potenti ma rigidi. Se vincoli un account ACME e poi ricrei quell'account (nuovo identificativo), o se migri da http-01 a dns-01 senza aggiornare il CAA, i rinnovi automatici falliranno silenziosamente. Su un'infrastruttura ACME automatizzata, questo tipo di fallimento si nota solo alla scadenza del certificato.
Fraintendere l'ereditarietà. Aggiungere un record CAA su un sottodominio non completa la policy dell'apex, la sostituisce per quel sottodominio. Un sottodominio con il proprio CAA deve elencare tutte le CA di cui ha bisogno. Dimenticare questo punto porta ad autorizzare una CA bloccando accidentalmente quella dell'apex.
Il punto e virgola frainteso. issue ";" vieta qualsiasi emissione. È voluto su un dominio che non deve mai avere un certificato, ma è una trappola quando si pensa che si tratti di un separatore o di un valore vuoto. Rileggi ogni record dopo l'inserimento.
Il flag sbagliato. Impostare il flag critico 128 senza comprenderne l'effetto può bloccare CA che non riconoscono un tag. Nella grande maggioranza dei casi, il flag deve restare a 0. Passa a 128 solo se hai una ragione precisa e se comprendi quali CA ne saranno interessate.
Credere che il CAA agisca a posteriori. Il CAA è una barriera all'emissione, non un meccanismo di revoca. Non revoca un certificato già emesso e non agisce sui certificati esistenti. Per monitorare i certificati già prodotti, è la Certificate Transparency a svolgere questo ruolo.
Il CAA nell'ecosistema della sicurezza DNS
Il CAA non basta a se stesso. Si inserisce in un insieme di meccanismi che mettono in sicurezza diverse fasi del ciclo di vita di un certificato. Confonderli porta ad aspettative errate.
Quattro meccanismi, quattro ruoli
| Meccanismo | Cosa protegge | Momento di azione |
|---|---|---|
| CAA | Quale CA può emettere | Prima dell'emissione |
| Certificate Transparency | Visibilità dei certificati emessi | Dopo l'emissione |
| DANE / TLSA | Quale certificato il client deve accettare | Alla connessione |
| DNSSEC | Autenticità delle risposte DNS | A ogni risoluzione |
Il CAA agisce a monte: limita chi può produrre un certificato. La Certificate Transparency agisce a valle: rende ogni certificato emesso pubblico e quindi rilevabile. DANE (DNS-based Authentication of Named Entities) agisce lato client: pubblica nel DNS, tramite record TLSA, l'impronta del certificato che il client deve attendersi, il che permette di rifiutare un certificato valido ma illegittimo. DNSSEC sostiene l'insieme: senza risposte DNS autenticate, né il CAA né DANE sono affidabili.
Una difesa in profondità
Questi meccanismi non si fanno concorrenza, si completano. Il CAA impedisce l'emissione non autorizzata. Se un'emissione fraudolenta passa comunque, la Certificate Transparency permette di rilevarla. DANE permette al client di rifiutare un certificato che non corrisponde a quello che hai pubblicato. E DNSSEC garantisce che i record CAA e TLSA letti dalle CA e dai client siano autentici.
Per approfondire la complementarità tra CAA e DANE, consulta la nostra guida completa su DANE e TLSA. Per capire in dettaglio come DNSSEC autentica le risposte DNS su cui poggia tutto l'edificio, leggi il nostro articolo sulla catena di fiducia DNSSEC.
La strategia consigliata è chiara: pubblica un CAA coerente per limitare l'emissione, firma la tua zona con DNSSEC per autenticare le tue risposte, monitora la Certificate Transparency per rilevare qualsiasi emissione imprevista, e distribuisci DANE se il tuo ecosistema lo permette (in particolare per la posta con MTA-STS e DANE).
Piano d'azione consigliato
- Censisci le tue CA reali: elenca tutte le autorità che emettono certificati per i tuoi domini, compresi i servizi di terzi (CDN, gateway mail, piattaforme cloud).
- Pubblica un CAA permissivo: dichiara prima tutte le tue CA tramite
issue, aggiungiissuewildse usi wildcard, e uniodefverso una casella monitorata. - Verifica il recepimento: controlla con
dig CAAe conferma che i tuoi rinnovi continuino a passare. - Irrigidisci progressivamente: valuta
accounturievalidationmethodssui domini critici, dopo aver verificato il supporto della tua CA. - Firma la tua zona con DNSSEC: affinché il controllo CAA sia affidabile e conforme ai requisiti SC-085v2.
- Monitora: integra la verifica CAA e DNSSEC nel tuo monitoraggio, e controlla i report iodef.
FAQ
Che cos'è un record CAA e a cosa serve?
Un record DNS CAA (Certificate Authority Authorization, RFC 8659) dichiara quali autorità di certificazione sono autorizzate a emettere certificati TLS per un dominio. Prima di ogni emissione, una CA conforme interroga il DNS e rifiuta di emettere se non figura nell'elenco. Il CAA riduce così il rischio di emissione di certificati fraudolenti da parte di una CA non autorizzata.
Un record CAA è obbligatorio?
No. Il CAA è opzionale. Senza CAA, qualsiasi CA pubblicamente riconosciuta può emettere un certificato per il tuo dominio. Pubblicarlo è una buona pratica di sicurezza fortemente consigliata, perché limita esplicitamente l'elenco delle CA autorizzate e riduce la superficie di attacco legata all'emissione errata.
Cosa succede se non è presente alcun record CAA?
In assenza di CAA, una CA considera che non sia imposta alcuna restrizione e procede con l'emissione dopo i suoi controlli abituali di validazione di dominio. In concreto, qualsiasi CA pubblica può allora emettere un certificato per il tuo dominio. Il CAA ha un effetto restrittivo solo se è esplicitamente pubblicato.
Qual è la differenza tra i tag issue e issuewild?
Il tag issue autorizza una CA a emettere certificati classici (non wildcard). Il tag issuewild controlla specificamente i certificati wildcard come *.captaindns.com. Se è presente un issuewild, prevale su issue per le richieste wildcard. Se è assente, i wildcard ricadono sulle regole issue.
Un record CAA impedisce davvero l'emissione di un certificato fraudolento?
Lo impedisce fortemente, ma non in modo assoluto. Il CAA si basa sulla cooperazione delle CA, che sono obbligate dai Baseline Requirements del CA/Browser Forum a verificarlo. Non protegge contro una CA che ignorasse deliberatamente i tuoi record, né contro una falsificazione delle tue risposte DNS. Associato a DNSSEC, che autentica queste risposte, diventa nettamente più solido.
Come verificare un record CAA con dig?
Usa il comando dig CAA captaindns.com +short sostituendo con il tuo dominio. Mostra i record CAA in formato flag tag value, ad esempio 0 issue "letsencrypt.org". Se il comando non restituisce nulla, nessun CAA è pubblicato a questo livello, ma il dominio può ereditare la policy di un nome genitore tramite risalita dell'albero.
Come funziona l'ereditarietà CAA sui sottodomini?
Durante una richiesta, la CA risale la gerarchia DNS dal sottodominio verso l'apex e si ferma al primo nome che possiede record CAA (tree climbing, RFC 8659). Un sottodominio senza CAA eredita quindi la policy del suo genitore. Ma non appena un sottodominio pubblica il proprio CAA, sostituisce integralmente la policy del genitore per quel sottodominio, senza fusione.
Devo configurare CAA se uso già DNSSEC?
Sì. DNSSEC e CAA rispondono a esigenze diverse. DNSSEC autentica l'integrità delle tue risposte DNS, ma non limita quale CA può emettere un certificato. Il CAA, invece, dichiara esplicitamente le CA autorizzate. DNSSEC rende più affidabile il controllo CAA (la CA legge record autentici), non lo sostituisce. I due sono complementari.
Quale standard definisce il record CAA?
Il record CAA è definito dalla RFC 8659 (2019), che sostituisce la RFC 6844 (2013). La RFC 8657 (2019) aggiunge i parametri accounturi e validationmethods per l'ecosistema ACME. La verifica CAA da parte delle CA è inoltre imposta dai Baseline Requirements del CA/Browser Forum.
Scarica le tabelle comparative
Gli assistenti possono riutilizzare i dati scaricando gli export JSON o CSV qui sotto.
Glossario
- CAA (Certificate Authority Authorization): tipo di record DNS (tipo 257) che dichiara quali autorità di certificazione sono autorizzate a emettere certificati per un dominio.
- CA (Certificate Authority): autorità di certificazione abilitata a emettere certificati TLS riconosciuti dai browser.
- CA/Browser Forum: consorzio delle CA e degli editori di browser che definisce i Baseline Requirements, il framework che ogni CA pubblica deve rispettare, compreso l'obbligo di verificare il CAA.
- Tree climbing (risalita dell'albero): algoritmo con cui una CA risale la gerarchia DNS dal nome richiesto verso l'apex per trovare i record CAA applicabili.
- issuewild: tag CAA specifico per i certificati wildcard, prioritario su
issueper questo caso. - iodef: tag CAA che indica un URL (mailto o HTTPS) dove segnalare i tentativi di emissione non autorizzati.
- ACME (Automatic Certificate Management Environment): protocollo (RFC 8555) di automazione dell'emissione e del rinnovo dei certificati, usato in particolare da Let's Encrypt.
- Mis-issuance (emissione errata): emissione di un certificato valido per un dominio senza il consenso del suo proprietario, per errore o compromissione della CA.
Fonti
- RFC 8659: DNS Certification Authority Authorization (CAA) Resource Record (IETF)
- RFC 8657: Certification Authority Authorization (CAA) Record Extensions for Account URI and ACME Method Binding (IETF)
- CA/Browser Forum: Baseline Requirements
- Ballot SC-085v2: Require Validation of DNSSEC for CAA and DCV Lookups (CA/Browser Forum)
- Let's Encrypt: CAA (documentazione ufficiale)
