CAA è un record DNS. Non è il certificato sul server. Identificativo Let’s Encrypt: letsencrypt.org. issue ";" chiede il divieto. SERVFAIL spesso è DNSSEC, non «CAA non supportato».
Il certificato TLS sta sul server. CAA sta nel DNS. Non è Let’s Encrypt, non è TLSA, non è HSTS. Verifica dell’8 ottobre 2026 su letsencrypt.org/docs/caa (last updated 4 ottobre 2026) e RFC 8659.
In breve: record DNS, RFC 8659, novembre 2019, obsoleta RFC 6844. Senza CAA ogni CA pubblica può emettere se valida il controllo del dominio. Identificativo Let’s Encrypt: letsencrypt.org. issue ";" chiede a tutti di non emettere. SERVFAIL in pagina è spesso DNSSEC o NOTIMP, non «CAA non supportato».
Cosa trovi in questo articolo
CAA è un record DNS, non il certificato
La pagina Certification Authority Authorization (CAA) di Let’s Encrypt, last updated 4 ottobre 2026, rilettura 8 ottobre 2026: CAA «is a type of DNS record that allows site owners to specify which Certificate Authorities (CAs) are allowed to issue certificates containing their domain names». Prima standard 2013; la versione in uso è RFC 8659 e RFC 8657, 2019. Di default «every public CA is allowed to issue certificates for any domain name in the public DNS, provided they validate control of that domain name». CAA riduce quel rischio. Il cluster è Infrastruttura. Il certificato a 90 giorni è un altro mestiere: Let’s Encrypt non è annuale. DNS, hosting e CDN restano tre pezzi: DNS, hosting, CDN.
RFC 8659, novembre 2019, Hallam-Baker, Stradling, Hoffman-Andrews, obsoleta RFC 6844. CAA lo consulta la CA prima di emettere. TLSA/DANE lo consulta chi verifica il certificato dopo. In RFC: «Conformance with a published CAA record is a necessary, but not sufficient, condition for the issuance of a certificate». Senza record CAA, l’insieme rilevante è vuoto: non c’è divieto. Let’s Encrypt, in pagina: se non ti interessa CAA, in genere non fai nulla (salvo gli errori sotto).
Let’s Encrypt, «Where to put the record»: di solito sul dominio registrato (example.org), così vale anche per i sottodomini. La CA rispetta il record CAA più vicino al nome per cui emette; un sottodominio può sovrascrivere. Segue i CNAME, «just like all other DNS requests». Un nome con CNAME, in pagina, non può avere altri record: niente conflitto tra CAA sull’alias e CAA sul target.
issue, issuewild, iodef, flag 128
Let’s Encrypt, formato: CAA <flags> <tag> <value>. Flag 0 nella maggior parte dei casi. Flag 128: bit critico; se la CA non riconosce il tag, si ferma e non emette. Tag in pagina: issue e, se serve un permesso diverso per i wildcard, issuewild. Identificativo Let’s Encrypt: letsencrypt.org (CP/CPS sezione 4.2.1, citata in pagina). Esempio in pagina: example.org CAA 0 issue "letsencrypt.org".
| In pagina / RFC 8659 (rilettura 8 ottobre 2026) | |
|---|---|
| issue | Chi può emettere per il nome (e, in assenza di issuewild, anche i wildcard). Più record issue sono additivi. |
| issue ";" | RFC 8659 §4.2: chiede che nessun Issuer emetta. Un valore che non rispetta l’ABNF si tratta come issuer vuoto. |
| issuewild | Solo certificati wildcard. RFC: ciascun issuewild ha precedenza su ciascun issue. |
| iodef | RFC 8659 §4.4: URL per segnalare richieste o emissioni che violano la policy. Scheme mailto, http o https. Non autorizza l’emissione. |
| validationmethods | Let’s Encrypt: http-01, dns-01, tls-alpn-01 dopo l’identificativo, separati da punto e virgola. |
| accounturi | Let’s Encrypt: URI dell’account ACME, forma https://acme-v02.api.letsencrypt.org/acme/acct/…. |
| Albero | RFC RelevantCAASet: si sale di etichetta finché si trova un RRset CAA, poi si ferma. Vuoto fino alla radice = nessun vincolo. |
RFC 8659: se nello stesso insieme ci sono un issue vuoto e un issue con dominio, vale il non vuoto (autorizzazioni additive). Let’s Encrypt controlla CAA prima di ogni certificato: un errore di lookup blocca, perché potrebbe esistere un record che vieta e non si vede.
SERVFAIL, NOTIMP, timeout
Let’s Encrypt, «CAA errors». SERVFAIL: il più comune, «most often» DNSSEC. Primo passo in pagina: un debugger DNSSEC (citano dnsviz.net). Secondo, senza DNSSEC: nameserver che risponde NOTIMP invece di NOERROR con risposta vuota: violazione di RFC 1035. Il provider, in pagina, non deve «supportare» CAA: deve rispondere NOERROR alle query di tipo sconosciuto. Timeout: spesso firewall che scarta i qtype sconosciuti. In pagina: riprovare su staging; se è permanente, ticket al DNS o cambio provider.
Errori da evitare
Trattare CAA come se fosse il certificato sul disco, o HSTS, o TLSA.
Mettere
letsencrypt.comnel record: l’identificativo in pagina èletsencrypt.org.Credere che «non supportiamo CAA» chiuda la pratica: in pagina basta RFC 1035, NOERROR.
Mettere
issue ";"e unissue "letsencrypt.org"sullo stesso nome aspettandosi il divieto: RFC, additive, vince il non vuoto.Usare Upgrade o Alt-Svc per «accendere CAA»: CAA è DNS, HTTP/3 è un altro canale. HTTP/3 sta in QUIC e Alt-Svc.
In sintesi
CAA è un record DNS. Let’s Encrypt legge letsencrypt.org. Senza record, nessuna restrizione. issue ";" chiede il divieto. SERVFAIL non è «CAA spento». Non è il certificato TLS. Si rilegge letsencrypt.org/docs/caa e RFC 8659 il giorno in cui si pubblica il record. Verifica dell’8 ottobre 2026.
