Here’s Why You Should Have a CAA DNS Record for Your HTTPS Website

This Friday, all certificate authorities will have to honor a Domain Name System (DNS) record that allows HTTPS website owners to restrict who can issue SSL certificates for their domain names. It’s a long-needed defense against the issuance of fraudulent certificates, a security risk that domain owners had few protections for until now.

The Problem: There are tens of certificate authorities (CAs) trusted in browsers and operating systems and any one of them can theoretically issue a valid SSL certificate for any website on the internet. Furthermore, many of these certificate authorities have subordinate CAs and resellers that are operated by separate organizations and which can also issue SSL certificates to end users.

This means that the security of the internet’s public key infrastructure depends on these organizations protecting their own systems from hackers and enforcing strict domain ownership checks before issuing certificates to people who request them.

Unfortunately, history has shown that even with periodic security audits and automated controls, cases of certificate “mis-issuance” — when certificates are issued to someone other than the domain owner — do happen. And not only do they happen, but it’s relatively hard to discover these breaches of trust externally.

A recent and very visible case led to Symantec deciding to sell its CA business to DigiCert after Google announced plans to gradually untrust all of its certificates in Chrome until October 2018. Google’s action comes in response to multiple cases of certificate mis-issuance discovered at Symantec or its partners since 2015 and is very significant since Symantec is one of the world’s largest CAs.

While the Symantec incidents had an internal cause and were the result of improper monitoring or failures to enforce existing policies, there have been cases at other CAs in the past where hackers broke in and obtained valid SSL certificates for high-profile domains. In 2011, fraudulent certificates for Google’s domains were obtained from a hacked certificate authority in the Netherlands and were used to launch a large-scale man-in-the-middle traffic interception attack against most internet users in Iran.

That attack was discovered because Chrome has an internal record of Google’s legitimate SSL certificates and reports back to the company if any unauthorized certificate for the company’s services is observed in the wild. There is a similar mechanism called HTTP Public Key Pinning (HPKP) that all website owners can use, but it is hard to implement and can leave websites inaccessible for long periods of time if configured incorrectly.

Enter Certification Authority Authorization (CAA)

The Certification Authority Authorization (CAA) is a DNS-based mechanism that allows domain administrators to specify which specific certificate authorities are allowed to issue SSL certificates for their domain names. CAA was standardized in 2013 but didn’t have too much impact until now because CAs were not forced to honor it. That’s no longer the case.

The CA/Browser Forum, an organization that combines major browser vendors and certificate authorities, voted earlier this year to make CAA checking mandatory as part of the certificate issuance process. The CA/Browser Forum maintains the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates,” an industry-accepted set of guidelines that all CAs have to follow.

The CAA requirement goes into effect on September 8 and most certificate authorities have already made changes to their systems in order to be compliant. DNS software and service providers have added support for this record type, but domain owners might want to check if their hosting companies allow adding it.

The CAA DNS record supports three properties: issue, issuewild and iodef. The “issue” and “issuewild” properties allow specifying one or more certificate authorities that are allowed to issue certificates or wildcard certificates for the parent domain. CAs listed under the “issue” property can issue all types of certificates, while those listed under “issuewild” can only issue wildcard certificates.

The “iodef” property is used for reporting purposes and can be very useful. It allows users to specify an email address or hostname where CAs will have to send reports if they receive requests to issue certificates but the domain’s CAA policy doesn’t authorize them. This provides a way for domain owners to learn if someone might try to fraudulently obtain certificates for their domain names.

Of course, if hackers manage to obtain a certificate from a CA authorized by the domain owner, there will be no report. Also, if hackers break into a CA they might be able, depending on what kind of access the gain, to bypass CAA checks entirely. So, CAA with its iodef reporting is not a silver bullet, but it’s better than nothing.

CAA policies can also be set per subdomain. For example, for subdomain.example.com, a CA will first check the CAA policy for the subdomain and then for example.com. If a CAA record exists for subdomain.example.com, it will take precedence over that for example.com.

This is useful for large companies that have many websites and services under the same domain name. These websites might be run by different teams or even external partners, such as marketing or PR agencies, which might have their own preferred SSL certificate providers.

“Be sure you use caution when creating CAA records,” CA service provider GlobalSign asserted in a blog post last month: “If you have other departments obtaining certificates you need to coordinate to be sure that all CAs in use will be added to your CAA records. Since CAA checking is mandatory and results in rejected orders that a CA can’t override, it’s important that the DNS administrator does not take down the company!”

Also, if you’re using a content delivery network or hosting provider that provides its own certificates through a different CA, this has to be taken into account.

Many CAs publish all the certificates they issue to a public log as part of a framework called Certificate Transparency (CT). It’s a good idea to check these CT logs — for example through services like crt.sh — in order to create an inventory of all SSL certificates used on your domains and subdomains and build a list of certificate providers for those websites.

Monitoring CT logs is also recommended because it can serve as a post-issuance detection mechanism for fraudulent certificates, while CAA provides a pre-issuance defense.