Qualys Blog

Ivan Ristic

CAA Mandated by CA/Browser Forum

Certification Authority Authorization (CAA), specified in RFC 6844 in 2013, is a proposal to improve the strength of the PKI ecosystem with a new control to restrict which CAs can issue certificates for a particular domain name. Although CAA had been in the proposed-standard state for more than 4 years, there was little obvious happening until very recently, with only a hundred or two hundred sites adopting it. But that’s going to change, because the CA/Browser Forum recently voted to mandate CAA support as part of its certificate issuance standard Baseline Requirements. The changes will become effective in September 2017.

The fact that any CA can issue a certificate for any domain name is commonly cited as the weakest aspect of the PKI ecosystem. Although CAs want to do the right thing, there are no technical controls that prevent them from doing whatever they chose to do. That’s why we say that the PKI ecosystem is a weak as the weakest link. With hundreds of CAs, there are potentially many weak links.

CAA creates a DNS mechanism that enables domain name owners to whitelist CAs that are allowed to issue certificates for their hostnames. It operates via a new DNS resource record (RR) called CAA (type 257). Owners can restrict certificate issuance by specifying zero or more CAs; if a CA is allowed to issue a certificate, their own hostname will be in the DNS record. For example, this is what someone’s CAA configuration could be (in the zone file):

example.org. CAA 128 issue "letsencrypt.org"

And that’s all there is to it. Before issuing a certificate, CAs are expected to check the DNS record and refuse issuance unless they find themselves on the whitelist. In addition to the “issue” directive from the example, two other directives are supported: “issuewild” that restricts issuance of wildcard certificates, and “iodef”, which provides support for notification in the cases something goes wrong. (In case you’re wondering, the number “128” is a flags byte with its highest bit set, meaning the directive use is considered critical and must be followed.)

At a high level, CAA has similar purpose to public key pinning (HPKP), but the implementation is entirely different. First, CAA prevents certificate issuance whereas HPKP is a run-time client-side control that prevents already-issued certificates from being seen as valid. In other words, CAA is for CAs, HPKP is for browsers. HPKP, which works by whitelisting public keys, is a strong technical control; in contrast CAA is largely an administrative control. While it’s expected that CAs will automatically check CAA before issuing certificates, what happens next is somewhat vague—they switch to manual processing and may end up issuing the certificate if they believe that the request is general. The main weakness of CAA compared to HPKP is that there are many CAs and that they all need to implement the checks correctly, as well as resist social engineering attacks when CAA is violated.

But this is not to say that CAA is useless, or inferior to HPKP. That’s because of the advantages, the main being that, unlike HPKP, which is potentially very dangerous, it’s not possible to abuse CAA and bring down a web property. Whereas HPKP can kill your business if you mess up, CAA will merely annoy you. In the end, one way to look at CAA is “public key pinning for normal web properties”, who would find HPKP to complicated and scary to use.

In case you’re wondering, SSL Labs already supports checking for CAA. You can see it in the report for google.com, for example. (It’s in the top section, along with the information on the key and first certificate.)

7 responses to “CAA Mandated by CA/Browser Forum”

  1. Will CAA implementation/non-implementation effect the ssllabs grade? If yes, when?

    If browser group decision if final, then I suggest to start grading as soon as possible (but not immediately). May I suggest the following path to grading:
    a) Announce that like at least in a month or so grading will change from A+ to A.
    b) In Summary section add additional info in orange tag (like e.g. if Forward Secrecy is not supported by browser) and write “CAA required in September 2017 (More)” and add link to this article. No grading is changed now, just additional info.
    c) After like a month or so, grade A+ to A.

    May I suggest to add to article some very basic DNS query command in order non-DNS admin can simple check if server supports CAA (for internal web servers). I have found something like this: https://www.classicyuppie.io/dns-crash-course-a-aaaa-ptr-records/

    • We don’t have immediate plans to start requiring CAA, but it’s very possible, given how easy it is to use safely.

      As for some DNS query commands, the issue might be that CAA uses a DNS RR type that not all command-line tools support yet. For example, the dig from MacPorts doesn’t, and I have to manually specify the type:

      $ dig google.com -t TYPE257

      In the output, you’ll get something like:

      google.com. 86399 IN TYPE257 \# 19 0005697373756573796D616E7465632E636F6D
      google.com. 86399 IN TYPE257 \# 15 00056973737565706B692E676F6F67

      If you ignore the first two bytes (4 characters in total) and decode remaining hexadecimal characters, you’ll get the CAA policies.

  2. Why shouldn’t the client look up the CAA record when resolving the hostname and not proceed unless the certificate presented chains up to the CAA allowed list? It seems like it would make for a much stronger control. Counting on every one of the CAs in the world to follow this rules is basically betting against the weather changing. It’s a guaranteed lost bet.

    • Actually, if you go back to read the archives of the discussions during the development of the HTTP public key pinning standard, there was some desire to make HPKP work in a similar way. Where it fell apart was the fact that there’d need to exist a repository of CA identities, which someone needs to manage and so on. In other words, it’s difficult to look at a CAA value, say “letsencrypt.org”, know that’s Let’s Encrypt, and correlate the observed certificate with them.

      There could be other problems, for example, a MITM could easily spoof CAA DNS entries and cause havoc. (I would expect CAs to employ multiple lookup positions in order to be resilient to spoofing attacks.) By the way, we already have DNSSEC+DANE, which allow DNS to be used for pinning. But they have their own problems.

      I think that CAA certainly adds value. After all, we’re now relying on CAs to do the right thing. If they all implement an automated CAA check before issuance, the world will be much better off.

Leave a Reply