6

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?

5
  • I would suggest to contact CA vendor for proper CAA record settings.
    – Crypt32
    Dec 1, 2017 at 11:45
  • That's what I said was unreliable because it's inconsistent and not automatable.
    – Synchro
    Dec 1, 2017 at 11:50
  • Just a remark: The issue field must contain a valid domain name. If you match letsencrypt.org to letsencrypt.org.example.com, you are doing it wrong, this is not a match.
    – Sven
    Dec 1, 2017 at 12:29
  • I'm not - my point was there is no field in the cert that is reliably verifiable
    – Synchro
    Dec 1, 2017 at 14:04
  • Another thought: if CAA records are only checked at time of certificate issue, having a site whose current cert does not match current CAA rules is not a cause for concern. Should it be?
    – Synchro
    Dec 1, 2017 at 14:35

1 Answer 1

7

The relevant RFC 6844 doesn't mandate any standard for the issuer, actually the opposite, it grants almost complete freedom:

The semantics of issuer-parameters are determined by the issuer alone.

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 domain comodoca.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 and trust-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.

Where should CAA issuer IDs be obtained from?

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."

2
  • That's a fair answer. Overall the entire mechanism appears very loosely defined, but I guess if you're a CA being asked to issue a cert, then you only need to be concerned about matching your own identifiers - but it's annoying for end users that finding the issuer IDs is not always straightforward – and on that subject, thanks for the Comodo link!
    – Synchro
    Dec 1, 2017 at 14:11
  • 2
    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."
    – HBruijn
    Dec 1, 2017 at 14:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .