DNS CAA Resource Record

Nel gennaio del 2013 con l’RFC 6844 è stato istituito un nuovo tipo di record DNS di risorsa denominato CAA (Certificate Authority Authorization) che consente di specificare una più Certification Authorities (CAs) autorizzate ad emettere certificati per il dominio. I record CAA consentono di evitare che vengano rilasciati certificati da CA non approvate.

L’RFC 6844 è stata oggetto di discussione da parte del CA/Browser Forum (Certification Authority/Browser) che è un gruppo senza fini di lucro composto da autorità di certificazione (CA, Certification Authority), venditori di browser Web e altre parti interessate che si occupa dell’implementazione delle best practices relative all’uso dei certificati SSL per la protezione delle comunicazioni degli utenti. Il CA/Browser Forum si occupa di definire le procedure da seguire per l’emissione dei diversi certificati.

L’8 settembre 2017 il CA/Browser Forum nello Ballot 187 ha deciso che il controllo dei record CAA da parte delle CA durante il processo di rilascio dei certificati è mandatorio, a riguardo si veda Ballot 187 – Make CAA Checking Mandatory:

“As part of the issuance process, the CA must check for a CAA record for each dNSName in the subjectAltName extension of the certificate to be issued, according to the procedure in RFC 6844, following the processing instructions set down in RFC 6844 for any records found. If the CA issues, they must do so within the TTL of the CAA record, or 8 hours, whichever is greater.”

Quindi sintetizzando ora quando una CA si appresta a rilasciare un certificato possono verificarsi tre differenti scenari:

1. Esiste un record CAA che indica la CA che sta emettendo il certificato autorevole e quindi la CA emette il certificato
2. Esiste un record CAA che indica come autorevole una CA diversa da quella sta emettendo il certificato e quindi la CA non emette il certificato
3. Non è stato configurato alcun record CAA e quindi la CA che sta emettendo il certificato si ritiene autorevole ed emette il certificato

Al link https://caatest.co.uk/ è possibile verificare se per un dominio è stato configurato un record CAA

Il 16 novembre 2017 Azure DNS ha annunciato il supporto ai record CAA, a riguardo si veda il post Azure DNS Updates – CAA Record Support and IPv6 Nameservers pubblicato sul blog dedicato ad Microsoft Azure

The CAA record type supports three properties:
   •Flags: An unsigned integer between 0 – 255, used to represent the critical flag that has a specific meaning per the RFC
   •Tag: An ASCII string which could be one of the following:
        •Issue: allows domain owners to specify CAs that are permitted to issue certificates (all types)
        •Issuewild: allows domain owners to specify CAs that are permitted to issue certificates (wildcard certs only)
       •Iodef: allows domain owners to specify an email address or hostname to which CAs can notify for certificate issuance requests for domain otherwise not authorized via CAA records
   •Value: the value associated with the specific tag used

You can create and manage CAA records via the Azure REST API, PowerShell and CLI.

Per quanto riguarda Let’s Encrypt, come indicato al seguente Certificate Authority Authorization (CAA), nel rispetto dell’implementazione dell’RFC 6844 e della modifica dell’8 settembre 2017 verifica i record CAA prima di rilasciare i certificati per un dominio, ma non supporta il “tree-climbing” che prevede il controllo anche dei domini padre per cui ha richiesto la rimozione al CAB Brower/Forum:

“The CAA RFC specifies an additional behavior called “tree-climbing” that requires CAs to also check the parent domains of the result of CNAME resolution. Let’s Encrypt does not implement tree climbing because it makes expressing certain CAA policies impossible. After discussion on the IETF mailing list, we achieved consensus that tree-climbing in CAA is not ideal, and there’s an erratum for the CAA RFC removing it. That erratum still needs to be voted in by the CA/Browser Forum by September 8 for it to to take effect for publicly trusted CAs.”

A riguardo di veda anche RFC Errata – RFC6844.

Di seguito alcuni esempi di record CAA:

Impostazione della CA Let’Encrypt per il dominio expample.com:
example.com. CAA 0 issue “letsencrypt.org”

Impostazione di due CA per il dominio expample.com:
example.com. CAA 0 issue “letsencrypt.org”
example.com. CAA 0 issue “identrust.com”

Impostazione di un’indirizzo mail a cui ricevere le violazioni alla policy:
example.com. CAA 0 iodef “mailto:example@example.com”

Al seguente CAA Record Helper è disponibile un generatore online di record di risorsa DNS di tipo CAA.