With the introduction of Certification Authority Authorization (CAA), domain holders can specify the Certificate Authorities authorized to issue certificates for the domain. This article explains CAA and its use.

Certification authorities classified as trusted in Mozilla, Google and Apple browsers have been required to take CAA entries into account when issuing certificates since 8 September 2017. This means that the majority of well-known certification authorities must support CAA, and it is worth domain owners making the effort.

Trusted certificates can therefore no longer be issued by virtually any certification authority. This restriction reduces the risk and increases the effort required for attackers attempting to obtain a valid certificate for attacks.

If an attacker succeeds in applying for a trusted certificate for a domain, this can be used to impersonate a legitimate website or to carry out man-in-the-middle attacks. Due to the trusted certificate, the user or their software would normally not detect these attacks. CAA attempts to prevent the erroneous issuance of a certificate by a trusted certification authority. The use of CAA should be viewed as part of a defence-in-depth strategy.

When selecting a certification authority, attention should be paid to support for and verification of CAA records. For security products, the adoption and use of new technologies to improve security is particularly important and a clear positive sign.

To use CAA, a corresponding entry is added to the Domain Name System (DNS) configuration. This results in low costs for the implementation and use of CAA for all domains. The use of CAA is particularly recommended for websites that use SSL/TLS for secure communication.

The following chapters examine the use of CAA and associated technical challenges.

A technical look at CAA

CAA is defined in RFC 6844 and introduces a new DNS Resource Record (RR) with which three different statements can currently be made for a domain. The various possible statements are discussed using the following example:

example.net. CAA 0 issue "ca.test" 
example.net. CAA 0 issue "other-ca.test; UID=123456" 
example.net. CAA 0 issuewild ";" 

intern.example.net. CAA 0 issue ";" 
intern.example.net. CAA 0 iodef "mailto:security@example.net" 

home.example.net. CAA 0 issuewild "ca.test"

A certification authority checks for CAA entries from left to right. If, for example, a certificate is requested for “admin.ch.eu.example.net”, the certification authority will search for CAA entries in the following order and apply the first one found:

1. admin.ch.eu.example.net.
2. ch.eu.example.net.
3. eu.example.net.
4. example.net.
5. net.

In our case, the certification authority would encounter the first CAA entry at “example.net” and apply it (the first three lines in our example). In this case, only the certification authorities ‘ca.test’ and ‘other-ca.test’ would be permitted to issue a certificate for ‘admin.ch.eu.example.net’. However, due to the third line, no certification authority would be permitted to issue wildcard certificates (e.g. *.eu.example.net).

issue entries thus define which certification authorities are permitted to issue a certificate for a specific domain. If an issuewild entry is missing, issue entries also apply to wildcard certificates.

The issuewild entry specifies which certification authorities are permitted to issue a wildcard certificate. If a wildcard certificate is to be issued and at least one issuewild entry exists, all issue entries are ignored.

The second line has the additional feature of containing extra information in the form of “UID=123456”. Such additional information is not standardised and depends on the certification authority. In our example, this additional information would specify that certificates from the provider “other-ca.test” may only be requested using the user account “123456”. This further reduces the attack surface.

[…]

example.net. CAA 0 issuewild ‘;’

intern.example.net. CAA 0 issue ‘;’

intern.example.net. CAA 0 iodef ‘mailto:security@example.net’

[…]

The three rules listed above apply to subdomains and the domain “intern.example.net”:

• No wildcard certificates may be issued. This is due to the issue entry for “intern.example.net” and not the issuewild for “example.net”. The CAA entries found first apply in each case, in accordance with the order shown above.
• No certificates may be issued for any domains or subdomains of “intern.example.net” due to the second rule. This is a more specific statement than the rules for “example.net”, where the issuance of certificates by two certification authorities is permitted. This more specific rule overrides the two less specific ones and applies exclusively (see the process described above for locating CAA records for a given domain).
• Unauthorised requests based on the CAA rules should be reported by the requested certification authority via email to «security@example.net» based on the iodef record.

iodef records ask certification authorities to report unauthorised requests. In addition to email addresses, HTTP/HTTPS URLs are also permitted as values. For further details, see RFC 6844, Section 5.4. The cyber experts at Oneconsult recommend specifying an email address when using iodef. However, developing a website capable of receiving and processing such information is not straightforward and involves additional costs.

[…]

home.example.net. CAA 0 issuewild ‘ca.test’

The last line in the example allows the certification authority ‘ca.test’ to issue wildcard certificates for domains and subdomains of ‘home.example.net’. Please note: Any certification authority may issue standard certificates! Due to the order in which CAA entries are searched, a certification authority would only apply the issuewild entry, and as long as no wildcard certificate is to be issued, there is no restriction on certification authorities. For this reason, it is important in such cases to add an additional issue entry. For example, with the value “;” to indicate that only wildcard certificates may be issued.

When creating such CAA records, the SSLMate web application is recommended. Based on just a few details, this generates the necessary CAA records for various DNS systems.

Potential pitfalls

When implementing CAA, the order in which certification authorities search for CAA records must be observed. This was described at the beginning of the previous chapter. Similarly, the difference between issue and issuewild is significant. If no wildcard certificates are used, a issuewild entry with the value ‘;’ is recommended. If, on the other hand, only wildcard certificates are issued, a corresponding issue entry is recommended. Incidentally, the use of wildcard certificates is discouraged for security reasons.

Due to the lack of integrity and authenticity guarantees in the DNS protocol, it is conceivable that attackers, whilst making unauthorised requests for certificates, could compromise the communication between the certification authority and the DNS server it uses, thereby manipulating or suppressing CAA records. This can be prevented by the domain owner through the use of ‘DNSSEC’. Certification authorities are also required to implement countermeasures against this type of attack. Such an attack would entail significant additional effort for the attackers, thereby further driving up the cost of the attack.

Conclusion

CAA primarily allows domain owners to specify which certification authorities are authorised to issue certificates for the domain. At the same time, it provides an additional control mechanism that certification authorities can use to prevent the erroneous issuance of certificates. Consequently, CAA records are only relevant at the time of a request for the issuance of a certificate. They are not an indicator of which certification authority must have signed a certificate and must not be used by the client for such verification. For this purpose, ‘DANE’ in combination with DNSSEC is envisaged.