Raphael Hiesgen, Teresa Lübeck, Thomas C. Schmidt, and Matthias Wählisch contributed to this work.
In this article, we give a brief overview of Certificate Transparency (CT), Certification Authority Authorization (CAA), and DNS Authentication of Named Entities (DANE), three approaches to addressing the problem of potentially mis-issued certificates. Through Internet-wide measurements, we provide insights into current deployments and discuss limitations.
Web PKI and safeguards against certificate mis-issuance
X.509 certificates are ubiquitous when it comes to authentication. Browsers authenticate hosts by verifying that the certificate delivered by a web server includes the corresponding hostname and that the certificate is signed by a trustworthy Certification Authority (CA). Trustworthy means that the CA meets our expectations of issuing certificates correctly. Each browser trusts a set of CAs based on pre-stored root certificates. For example, the Mozilla trust store used by Firefox browsers marks root certificates from 121 organizations as trustworthy.
Certificates, CAs, and trust stores build the basis of the web PKI, which handles the issuance, distribution, and management of web certificates. The trust framework of web PKI concentrates a significant amount of power in the hands of a limited number of CAs by allowing them to certify any arbitrary domain name. Consequently, if a single CA is compromised like DigiNotar in 2011 or misbehaves like Entrust in 2024, the security of the web as a whole is put at risk.
In principle, there are prevention and mitigation options to cope with incorrectly issued certificates. CAA and DANE belong to the class of prevention since they enable name owners to specify PKI-related material in the DNS, which can be verified by CAs before issuing certificates or end users before establishing trusted communication. CAA restricts CAs to those that are allowed to certify names from a given namespace, and DANE allows name owners to describe which certificates to be expected at a given service endpoint (such as HTTPS) using TLSA records. In contrast to CAA and DANE, CT helps retrospectively. CT makes certificates available in public logs and thus allows for monitoring, to execute informed and fast revocation.
Recently, we performed active and passive measurements to study CAA, CT, and DANE deployment as well as the way they interlink. While all CAs log their issued certificates in at least two CT logs, we observe that name owners are reluctant to use CAA or DANE. Unfortunately, misconfigurations, specifically of DANE, are widespread.
CT, CAA, and DANE in action
Our analysis of current deployments was based on 4M domain names extracted from the Tranco top list. For each domain name, we queried CAA and DANE TLSA records, fetched server certificates, and, additionally, collected respective certificates from CT logs.
Figure 1 depicts the amount of domain names in our dataset that support each technology, exclusively and in combination with others. Only about 5% of all measured domain names make use of CAA. DANE penetration reaches just 0.1%.
The higher penetration rate of CAA is partly due to automatic deployment processes and does not necessarily indicate higher user awareness. Cloudflare, for example, adds CAA records on behalf of customers. The low adoption of DANE is very likely rooted in the lack of DANE support in major browsers. Even if name owners create DANE records, this would not have an impact on web users because browsers currently do not consider DANE TLSA records at all.
In our dataset, about 99% of the CAA records comply with the corresponding server certificates (see Figure 2). In some cases, ambiguous CAA identifiers caused false negatives in our validation. TrustAsia, for example, only accepts trustasia.com according to its CP/CPS documents, whereas our data shows that in practice it also accepts identifiers for Sectigo (for example, sectigo.com). For a small fraction, we assume CA misbehaviour, such as faulty CAA verification. In one case (GoDaddy), we confirm with the CA that their implementation has been faulty (see Bugzilla Bug 1904748 and Bugzilla Bug 1904749). There are notable cases where domains have CAA records, but these records do not restrict certificate issuance. An example of configuration leading to such implicit matches are usage of non-standard CAA tags. Among these, some are unintentional, for instance, due to the misspelling of a tag that constrains issuance (isssue instead of issue).
In contrast to CAA, DANE deployment is more characterized by misconfigurations (Figure 3).
Only 70% of DANE-enabled server certificates comply with the corresponding TLSA records. Every third TLSA record is delivered by a nameserver that does not support DNSSEC even though DNSSEC is mandatory in DANE. A small fraction of hosts provide invalid certificates because they are expired or self-signed. Those certificates, however, are correctly authenticated by TLSA records. In cases when certificates do not comply with their TLSA records, we find certificates in the CT logs but those (root) certificates were expired or even removed from trust stores (Figure 4).
Overall, it seems that DANE maintenance, particularly synchronizing DANE TLSA records with the deployed certs, is rather challenging for name owners. Yet, for cases with proper DANE configuration, we also observe a much higher usage of correctly configured and matching CAA records.
Are CT, CAA, and DANE useful?
Illegitimate certificates are a real problem. However, our data shows that name owners do not often make use of countermeasures. We will now discuss whether a larger deployment of CT, CAA, and DANE would help to resolve misissuance.
Certificate Transparency
CT was not designed to prevent CA misbehaviour but to detect illegitimate certificates after issuance, and in that regard, it has been somewhat effective (see Google Security Blog and Hacker News).
A significant amount of certificates are stored in CT logs because major browser vendors (Chrome and Safari) require certificates to be logged, otherwise, certificates are considered less trustworthy within the browser. Whether this transparency is abused or certificates are monitored is another story. As part of our research, out of more than 1,000 mis-issued GoDaddy certificates, we found that not a single one was detected by their owners. So far, CT logs have primarily been utilized by tech companies with resources and expertise, like Google and Facebook, as well as researchers.
DANE
DANE also cannot prevent certificate mis-issuance, but it can prevent those certificates from being accepted by users. Its main application has proven elsewhere, outside the web, like securing mail servers. Low deployment of DANE is caused by two main factors. Firstly, no major browser supports DANE. Secondly, DNSSEC, as a requirement for DANE, is not widely supported by either resolvers or nameservers. Unless these two obstacles are removed, the benefits of DANE will remain negligible in practice.
CAA
The actual effectiveness of CAA is hard to assess due to two deployment obstacles. Firstly, CAA policy violations are in practice not reported back to name owners even if it is explicitly requested (using the CAA iodef tag). Secondly, the relationship between CAs and CAA identifiers that they accept is not always clear. ZeroSSL users, for example, are instructed to use sectigo.com as a CAA identifier yet they are not informed that doing so allows other Sectigo subsidiaries and brands (such as TrustAsia and GÉANT) to issue certificates. As such, the current implementation of CAA by CAs does not allow the clear-cut definition of constraints that the CAA specification aims for. Additionally, CAA records are, in contrast to CT and DANE, not cryptographically secured and thus not verifiable by third parties.
Lessons learned and the way forward
The web PKI builds the basis for secure communication over the web. Unfortunately, unverified issuance of certificates is a reality and poses a real threat to the Internet. Although remedies exist, we have shown that these are not widely used. Furthermore, we pinpointed the limits and challenges of each solution. Making progress requires efforts from CAs, browsers, and name owners, as well as the provision of proper tools.
First and foremost, we encourage owners of domain names to enable DNSSEC since this will enable third parties to verify the metadata of a name, including certificate information such as legitimate public keys or issuing CAs. Browser vendors should give incentives by making DANE mandatory, similar to the requirement to document certificates in CT logs.
CAA should not be misunderstood. It has not been proposed to enable end users to identify illegitimate CAs or to mitigate malicious CAs, but rather to document CAs that a name owner trusts. Furthermore, CAA can prevent misconfigurations on the CA side by providing a common interface between the name owner and CA. To use this interface effectively, much clearer definitions of semantics and syntax should be provided by CAs.
This research was originally published at IEEE/IFIP TMA 2024. Read the paper ‘Do CAA, CT, and DANE Interlink in Certificate Deployments? A Web PKI Measurement Study‘ for more details.
Pouyan is a final-year PhD student and a research associate in the Chair of Distributed and Networked Systems at TU Dresden. His research focuses on communication networks for emergencies and crises, particularly object security in fragmented and challenged networks.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.