Record CAA per autorizzare le Certification Authority

In breve: I record DNS CAA permettono al titolare di un dominio di dichiarare quali Certification Authority sono autorizzate a emettere certificati per quel nome. Sono un controllo al momento dell’emissione: non sostituiscono la validazione TLS del browser e non revocano certificati già emessi.

In sintesi

I record DNS CAA permettono al titolare di un dominio di dichiarare quali Certification Authority sono autorizzate a emettere certificati per quel nome. Sono un controllo al momento dell’emissione: non sostituiscono la validazione TLS del browser e non revocano certificati già emessi.

Come funziona il record CAA

Un record CAA contiene flag, tag e valore. I tag più usati sono issue, per autorizzare l’emissione ordinaria, issuewild, per specificare l’autorizzazione relativa ai certificati wildcard, e iodef, che può indicare un canale per segnalazioni. Un dominio può pubblicare più record CAA quando autorizza più CA o necessita di policy diverse.

Prima di emettere un certificato, una CA conforme determina il CAA rilevante seguendo le regole dello standard. La ricerca può risalire la gerarchia DNS finché trova un RRset applicabile. Per questo un record pubblicato su un dominio superiore può influire sui nomi sottostanti quando non esiste una policy più specifica.

Esempi di sintassi

La forma generale è CAA <flags> <tag> <value>. Esempi concettuali:

example.com.  CAA 0 issue "ca.example"
example.com.  CAA 0 issuewild "ca.example"
example.com.  CAA 0 iodef "mailto:security@example.com"

Il valore reale dell’issuer deve essere quello documentato dalla Certification Authority scelta. Non copiarlo da esempi generici: provider diversi possono richiedere identificatori o parametri specifici.

Controlli prima dell’emissione

1. Interroga l’autorevole con dig example.com CAA e verifica la risposta senza affidarti soltanto al pannello DNS.
2. Se richiedi un wildcard, controlla esplicitamente la policy issuewild e la relazione con gli eventuali record issue.
3. Verifica eventuali CNAME: la CA deve seguire le regole di elaborazione previste dallo standard e una configurazione inattesa può cambiare il CAA rilevante.
4. Controlla DNSSEC quando presente; una zona bogus può causare errori di risoluzione indipendenti dalla sintassi CAA.
5. Dopo una modifica aspetta il TTL necessario e ripeti la query da più resolver, ma usa l’autorevole come riferimento principale.

Errori comuni

• Autorizzare una CA diversa da quella realmente usata dal sistema di rinnovo.
• Impostare issue ma dimenticare la policy desiderata per i wildcard.
• Pensare che CAA renda “non valido” un certificato già emesso: il controllo riguarda l’autorizzazione all’emissione.
• Confondere CAA con TLSA/DANE: hanno ruoli differenti nel ciclo del certificato.
• Modificare CAA durante un incidente senza documentare il valore precedente e senza verificare quale client ACME o CA debba rinnovare il certificato.

Verifica finale

La policy è corretta quando l’autorevole restituisce soltanto le autorizzazioni previste e il sistema di emissione/rinnovo continua a funzionare. Dopo ogni cambio di CA, controlla CAA prima di arrivare vicino alla scadenza del certificato: un rinnovo bloccato per policy incoerente può trasformarsi in un’interruzione HTTPS evitabile.

Guide Xlogic correlate

• Record DS: collegare DNSSEC al registro
• Child nameserver e glue record: configurazione corretta
• Glue record errati dopo cambio IP

Fonti

• RFC 8659 — DNS Certification Authority Authorization (CAA)
• RFC 1035 — Domain Names: Implementation and Specification

Domande frequenti