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 genuine. 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.)

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

      • “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.”

        Do you have a blog about DNSSEC+DANE and their problems?
        Does any DNS/HTTPS tech prevent MITM attacks or DNS spoofing?

  3. Sure would be nice if they would eat their own dog food on this one. No CAA record. Only realized it because my browser refused to connect – they don’t offer TLS 1.2 or forward secrecy.

    • Not sure what the argument was behind not using TXT records. Perhaps that they’re already heavily overloaded and exceeding the size limit? There is indeed a problem with CAA in that many DNS providers are slow to add support for this new RR. As for the CAs, they’ll just have to support it.

  4. Within “… if they believe that the request is general”, I bet the intended word was “genuine” rather than general.

  5. How about DANE/TLSA checking? This would also include DNSSEC checks, but these are already recommended to secure the CAA records.

  6. Maybe I’m blind, but I can’t find anything about CAA in the API-documentation nor the result of the API-call.
    Can you please give me any pointer or update your functionality?

    • Hi Dmitry. You only need one configuration entry for the root example.com. Whatever you set there will have effect on the entire hierarchy. (Unless, of course, you add different configuration records to the subhosts.)

  7. I have just implemented DNS CAA for our site and was pleased to see that it is one of the “highlighted” (explicitly mentioned in the summary) features on the SSL test.

    This led me to the question: What are all the highlighted features?

    I know of:
    – HSTS with long duration
    – DNS CAA

    Are there more? Couldn’t find this info in the rating guide. Would be a nice addition there. Also what are the features which are shown in green in the details section (e.g. EV, Certificate Transparency, DNS CAA, Trustec, HSTS, Preload)?

    • There’s also HPKP, which you could see, for example, on github.com. This feature is not appropriate for most sites, however.

      HSTS preloading should probably be highlighted. I’d also love to encourage the use of OCSP stapling, but that’s not yet feasible.

  8. But what prevents compromised CA to sign csrs for domains it shouldn’t?

    Biggest flaw in current system is the that CAs can issue certificate for any domain. I fail to see how CAA prevents that.

    • Technically, nothing. The main purpose of CAA is to prevent wrong automated issuance. If CAA fails then the CA must investigate, which involves thinking and procedures, meaning the bar for successful exploitation is higher.

  9. Hi

    If i have wild certificates from Thawte and Digicert for “example.com”
    And if i have dns records:
    example.com (Thawte cert)
    first.example.com (Thawte cert)
    second.example.com (Thawte cert)
    third.example.com (Digicert cert)
    tens.example.com (Digicert cert)

    I need to specify:
    example.com. IN CAA 0 issue “digicert.com”
    example.com. IN CAA 0 issue “thawte.com”
    first.example.com. IN CAA 0 issue “thawte.com”
    second.example.com. IN CAA 0 issue “thawte.com”
    third.example.com. IN CAA 0 issue “digicert.com”
    tens.example.com. IN CAA 0 issue “digicert.com”

    Is it correct i understand?

    • If you don’t want to be specific about which CA is able to issue for which subdomain — in other words, both Thawte and DigiCert can issue certificates freely, then you only need two top-level DNS RR entries:

      example.com. IN CAA 0 issue “digicert.com”
      example.com. IN CAA 0 issue “thawte.com”

  10. Why do they make the web/browser so complicated?
    I know that CA is a multi-$$$$ business, and no one wants’ to give it up.

    It would be easier to give the security to the domain owner or the domain registrar.
    So the browser don’t have to be setting rules how the net should work, nor anyone else.
    – i have a software that use openSSL and generate a (RSA/EC/etc..) key pair (private & public).
    – the software save the private key, and does not display it, it store it in hardware or software.
    – the software display the public key, & save it to a file public.key
    – the domain owner create a HPKP dns record with the public key.
    – then use the software to create certificate with the private key, but only for the domains with the public key in the dns record.

    Then all the browser has to do a dns lookup on the website domain name for the public key to decode the certificate. the browser will then open an encrypted cache file, and save the website domain name, a hash of the certificate & hash of the public key, with a time to live value of 3 hrs (so as to check if the public key has changed).


  11. Is there a list of DNS registrars/free DNS services that support CAA? Azure DNS doesn’t support it yet 🙁

Leave a Reply