CAA Mandated by CA/Browser Forum
Last updated on: February 17, 2022
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.
Free Trial
Assess, Manage, Detect, and Respond with Qualys VMDR
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.)
Is there a canonical listing somewhere of each CA’s domain name, so I can start creating CAA records?
Frank, I think the closest thing to what you’re looking for is the “CAA Record Generator” from SSLMate: https://sslmate.com/labs/caa/
That’s fantastic, thanks.
A few years late to the discovery of these new rules. Thanks for linking the record generator. Very helpful.
Even later :)
I found of the list of CA domain names here.
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00023
Hope this helps someone.
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:
;; ANSWER SECTION:
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.
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?
When it comes to DNSSEC (and DANE), the main problem is that there isn’t a clear consensus that it’s the way forward. There are valid arguments for and against it, and there are also some technical issues. Here’s a blog post that’s heavily against: https://sockpuppet.org/blog/2015/01/15/against-dnssec/
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.
Wow, two years later and they still haven’t implemented it for their own site. https://www.ssllabs.com/ssltest/analyze.html?d=cabforum.org
Why not implement this with a TXT record. I sense a SPF-esque disturbance in the force…
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.
This is what I’m facing almost a year later with a leading Swiss hosting provider that published an uptake of 16.3% in 2017 in hosted domains. The choice for where a DNS service is hosted is almost never technically motivated and can be separate from hosting of the services. Especially for starting businesses, who want to limit the (recurring) costs for “complicated things that are apparently required”.
Within “… if they believe that the request is general”, I bet the intended word was “genuine” rather than general.
You’re right. Fixed now, thanks!
How about DANE/TLSA checking? This would also include DNSSEC checks, but these are already recommended to secure the CAA records.
For web sites, which is only what SSL Labs is currently checking, DANE has little value, given that no browser vendor has support for them.
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?
You’re probably looking at the v2 API, which is no longer updated. The CAA information is available in the v3 API. On GitHub, take a look at the master branch.
Is it valid to publish CAA records for subdomains?
Yes, it is, and it’s of course possible to have different CAA settings on different hosts.
I just set up a CAA record for a subdomain, but can’t set a root CAA record (for practical reasons, we just manage 1 subdomain, other subs are not under our control).
But when I validate the subdomain certificate, it says no CAA record is found.
Is a root CAA always required in addition to a subdomain CAA?
Please tell me, to get a certificate for: example.com and http://www.example.com
I need to specify:
example.com. IN CAA 0 issue “letsencrypt.org”
http://www.example.com. IN CAA 0 issue “letsencrypt.org”
Or only
example.com. IN CAA 0 issue “letsencrypt.org”
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.)
If that’s the case, then the SSL Server Test has a bug. I’ve set the CAA value for my root domain (eg. example.com). When I check the root domain, I get the green “Yes” for “DNS CAA”. If I check any sub domain I get the yellow “No (more info)” line.
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.
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.
You’re right that CAA doesn’t prevent human errors or malicious intent when a CA is compromised. But to compensate for that you could additionally monitor the Certificate Transparency Logs and implement the Expect-CT header.
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”
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.
eg:
– 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).
thanks.
Well, I think you’ve pretty much described DNSSEC + DANE :)
Is there a list of DNS registrars/free DNS services that support CAA? Azure DNS doesn’t support it yet :(
For whatever reason, SSL Labs only showed my domain using DNS CAA once I added a iodef record. Even with Godaddy automatically setting up “issue” and “issuewild” CAA records in my DNS zones, ssllabs said DNS CAA = no until the iodef record was added.
Did/Does CAA increase your score after adding iodef?
No. CAA as a whole doesn’t currently impact the score.
Here’s a concise explanation on adding CAA Records in GoDaddy DNS: https://michaelstenberg.com/adding-caa-records-in-godaddy-dns/
Gandi DNS Hosting: Switch to “Expert Mode”
#(non *wildcard certs)
—
@ 10800 IN CAA 0 issue “letsencrypt.org”
@ 10800 IN CAA 0 issuewild “;”
—
Hi all,
I notice that in SSLLabs site reports, CAA is marked in Yellow if the domain does not specify one. Does that mean that Qualy’s will soon start “dinging” sites that don’t have CAA statements? Seems like yellow wording is only used for sketchy things, like allowing TLS 1.0 and 1.1, weak ciphers etc.
I ask because in the company I work for, a small company dealing in non-critical services, the threat of someone just randomly buying a certificate from somewhere is not really an issue (though I accept that it might be an issue for larger entities). Basically, right now we use Let’s Encrypt for most things, but if that ever failed, we’d want to buy certificates from whoever was cheapest with the least amount of hassle.
Also, is there a syntax in writing CAA statements the equivalent of “no restrictions”? That is to explicitly state in a CAA record that we don’t care who issues our certificates?
So as a website owner, if it comes up after an SSL Labs scan, under “Certificate #1: RSA 2048 bits, Server Key and Certificate #1, it says ‘DNS CAA No (more info)’ ”
What are we supopose to do at this point or can we even do, or is this our webhosting provider’s problem? Under the full SSL Labs scan, it would be easier if it would state what us site owners CAN and CANNOT do- what parts we can fix ourselves, and what parts are under control of the webhosting provider.
Thanks
Because a rouge CA who was going to illegally issue a certificate is now going to first check CAA records and decide to be honest instead when they’re not listed?
This is the stupidest “security” idea I’ve ever heard of, undoubtedly dreamed up by a committee of idiots.
It blows my mind how the solution literally does nothing whatsoever to address the stated threat, and yet this pile of garbage idea somehow made it into a standard!
I’d like to slightly disagree with your categorisation.
Instead of ‘a committee of idiots’,
I call them ‘a pack of technocrats’!
Question about the value 128. You say “(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.)”
Are you sure 128 is the best value there?
I noticed that NameCheap doesn’t allow choosing a numeric value, and selects 0 for me after I submit the record. Their support said “that’s fine” and it passes qualys’ test. I thought more detail on why you recommend 128 would be helpful.
If 128 is better than 0 then that should be reflected in the qualys SSL test.
But after some googling, https://datatracker.ietf.org/doc/html/rfc8659#section-4.1 clears it right up though.
The leftmost bit is the only one that has a meaning today. on=issuer critical.
leftmostbit’s value is 128 in decimal. So if your dns server represents the flags field as a decimal number (and most do), 128 is what you want to put there.
BS!
it’s now 2022, 5 years ahead of this post and NOTHING has changed for a better. In fact, it only worsened,
BS AI IT technocrat mislead talk!
as usual.
Not a proposal to improve the strength of the PKI ecosystem but an effort to squeeze more money out of people for another, pretentious, non-functioning slimy and misleadingly advertised upgrade. By all means, challenge me! Where is your improvement (other than in your marketing crap)? ???
The CAA record allows the domain OWNER (you) to specify the CAs, which can be anything, including free Let’s Encrypt. What kind of squeezed money are you talking about? You clearly don’t understand the concept in the slightest.