The Certificate Authority Authorization (CAA) DNS record type includes an issue
parameter (also issuewild
) that designates an identifier for a Certificate Authority allowed to issue certificates for your domain. That's ok, but it's a little vague.
When setting the value in your own CAA records, how are you supposed to find out what the exact value should be for your CA(s)? In the case of letsencrypt, they provide a document here that mentions that their issue identifier is letsencrypt.org
, and that it's also documented in their Certification Practice Statement section 4.2.1. If I inspect the certificate, I can see various fields in it, however, none match this string exactly, though there are some that contain it. That doesn't seem like a rigorous or reliable way of ensuring that the CA matches what's in the CAA record - for example what's stopping it being matched by letsencrypt.org.evilcorp.com
?
This is all workable from a human perspective, but not very machine readable, and is unique to this CA.
I also have certs from Comodo, and I've found various non-authoritative sources saying that their CAA issue id is comodoca.com
(and others saying it's comodo.com
), but I've not found an official doc like letsencrypt have for that. The comodoca.com
string does appear in some fields of my cert, but not in a context I'd expect it to be found reliably - for example the issuer name is COMODO ECC Domain Validation Secure Server CA (COMODO CA Limited from GB)
, the CRL is http://crl.comodoca.com/COMODOECCDomainValidationSecureServerCA.crl
and the OCSP URI is http://ocsp.comodoca.com
.
SSLMate have a CAA record generator and it includes a list of CAs and their issuer IDs - but where was that info obtained from?
Now consider the validation case - given a cert and one or more CAA issuer IDs, what elements in the cert should we expect to match the CAA issuer exactly? Or is that info obtained from some other service like a CT log?
So, in short, where should CAA issuer IDs be obtained from and how should they be validated reliably?
The relevant
RFC 6844
doesn't mandate any standard for the issuer, actually the opposite, it grants almost complete freedom:But to take a step back: CAA records were not intended, as far as I know, to be used by end-users to validate if the TLS certificate they get presented with is issued by the correct certificate issuer.
It was intended to only be used by a (reputable) certificate issuer to validate that they are allowed to issue a (new) certificate for that host/domain.
It is only the certificate issuer that needs to check if whatever they expect/require is present in the CAA record, if a CAA record exists.
Your certificate issuer, i.e. your CA, will need to communicate which domain(s) they recognise in the CAA issue records. And also which, if any, other parameters they require.
For example: Comodo, which uses
comodo.com
for its online brand, is completely free to recognise the completely different domaincomodoca.com
in CAA records. Actually CAs are also not restricted to only recognise a single domain - Comodo for instance recognises four different ones:comodo.com
,comodoca.com
,usertrust.com
andtrust-provider.com
Note: CAA records are only used when issuing a certificate. Reverse engineering what the CAA record should be from valid certificates that have already been issued serves no immediate purpose.
As far as I know there is nothing that you can easily automate with regards to that, but for a manual approach: The CA/Browser forum requires a uniform location for that info to be published:
"Effective as of 8 September 2017, section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement SHALL state the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements. It shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA "
issue
" or "issuewild
" records as permitting it to issue."