A surprisingly hard, and widely misunderstood, problem with SSL certificates is figuring out what organization (called a Certificate Authority, or CA) issued a certificate. This information is useful for several reasons:
- You’ve discovered an unauthorized certificate for your domain via Certificate Transparency logs and need to contact the CA to get the certificate revoked.
- You’ve discovered a certificate via Certificate Transparency and want to know if it was issued by one of your authorized certificate providers.
- You’re a researcher studying the certificate ecosystem and want to count how many certificates each CA has issued.
On the surface, this looks easy — every certificate contains an issuer field with human-readable attributes, including an organization name. Problem solved, right?
Not so fast! A certificate’s issuer field is frequently a lie that tells you nothing about the organization that really issued the certificate. Just look at the certificate chain currently served by doordash.com:
According to this, DoorDash’s certificate was issued by an intermediate certificate belonging to ‘Cloudflare, Inc.’, which was issued by a root certificate belonging to ‘Baltimore’. Except Cloudflare is not a CA, and Baltimore is a city.
In reality, both DoorDash’s certificate and the intermediate certificate were issued by DigiCert, a name that is mentioned nowhere in the above chain. What’s going on?
First, Cloudflare has paid DigiCert to create and operate an intermediate certificate with Cloudflare’s name in it. DigiCert, not Cloudflare, controls the private key and performs the security-critical validation steps prior to issuance. All Cloudflare does is make an API call to DigiCert. Certificates issued from the ‘Cloudflare’ intermediate are functionally no different from certificates issued from any of DigiCert’s other intermediates. This type of white labelling is common in the certificate industry since it lets companies appear to be CAs without the expense of operating a CA.
That time everyone freaked out about Blue Coat
In 2016, Symantec created an intermediate certificate with ‘Blue Coat’ in the organization name. This alarmed many non-experts who thought Blue Coat, a notorious maker of TLS interception devices, was now operating a CA. In reality, it was just a white-label Symantec intermediate certificate, operated by Symantec under their normal audits with their normal validation procedures, and it posed no more risk to the Internet than any of the other intermediate certificates operated by Symantec.
What about ‘Baltimore’? That’s short for Baltimore Technologies, a now-defunct infosec company that acquired GTE‘s CA subsidiary (named CyberTrust) in 2000, which they then sold to a company named Betrusted in 2003. Betrusted then merged with TruSecure in 2004, which rebranded back to CyberTrust. It was then acquired by Verizon in 2007, who then sold the private keys for their root certificates to DigiCert in 2015. So ‘Baltimore’ hasn’t been accurate since 2003, and the true owner has changed four times since then.
Mergers and acquisitions are common in the certificate industry, and since the issuer name is baked into certificates, the old name can persist long after a different organization takes over. Even once old certificates expire, the acquiring CA might keep using the old name for branding purposes. Consider Thawte, which despite not existing since 1999, could still be found in new certificates as recently as 2017 (Thawte was sold to Verisign, then Symantec, and then DigiCert, who finally stopped putting ‘Thawte’ in the issuer organization name).
Consequentially, the certificate issuer field is completely useless for human consumption and causes constant confusion. People wonder why they get Certificate Transparency alerts for certificates issued by ‘Cloudflare’ when their CAA record has only digicert.com in it. Worse, people have trouble revoking certificates. Consider this incident where someone tried to report a compromised private key to the certificate reseller named in the certificate issuer field, who failed to revoke the certificate and then ghosted the reporter. If the compromised key had been reported to the true CA, the CA would have been required to revoke and respond within 24 hours.
I think certificate tools should do a better job helping people understand who issued certificates, so a few years ago I started maintaining a database that maps certificate issuers to their actual organization names. When Cert Spotter sends an alert about an unknown certificate found in Certificate Transparency logs, it shows the name from this database — not the name from the certificate issuer field. It also includes the correct contact information for requesting revocation.
As of January 2023, the same information is available through SSLMate’s Certificate Transparency Search API, letting you integrate useful certificate issuer information into your own applications. Here’s what the API looks like for the doordash.com certificate (some fields have been truncated for clarity)
{
"id":"3779499808",
"tbs_sha256":"eb3782390d9fb3f3219129212b244cc34958774ba289453a0a584e089d0f2b86",
"cert_sha256":"6e5c90eb2e592f95fabf68afaf7d05c53cbd536eee7ee2057fde63704f3e1ca1",
"dns_names":["*.doordash.com","doordash.com","sni.cloudflaressl.com"],
"pubkey_sha256":"456d8df5c5b1097c775a778d92f50d49b25720f672fcb0b8a75020fc85110bea",
"issuer":{
"friendly_name":"DigiCert",
"website":"https://www.digicert.com/",
"caa_domains":["digicert.com","symantec.com","geotrust.com","rapidssl.com", ...],
"operator":{"name":"DigiCert","website":"https://www.digicert.com/"},
"pubkey_sha256":"144cd5394a78745de02346553d126115b48955747eb9098c1fae7186cd60947e",
"name":"C=US, O=\"Cloudflare, Inc.\", CN=Cloudflare Inc ECC CA-3"
},
"not_before":"2022-05-29T00:00:00Z",
"not_after":"2023-05-29T23:59:59Z",
"revoked":false,
"problem_reporting":"Send email to revoke@digicert.com or visit https://problemreport.digicert.com/"
}Note the following fields:
- The
friendly_namefield contains ‘DigiCert’, not ‘Cloudflare’. This field is useful for displaying to humans. - The
caa_domainsfield contains the CAA domains used by the CA. You can compare this array against your domain’s CAA record set to determine if the certificate is authorized — at least one of the domains in the array should also be in your CAA record set. - The
operatorfield contains details about the company that operates the CA. In this example, the operator name is the same as the friendly name, but later in this post, I’ll describe an edge case where they are different. - The
problem_reportingfield contains instructions on how to contact the CA to request the certificate be revoked.
The data comes from a few places:
- The Common CA Database (CCADB)‘s
AllCertificateRecordsreport, which is a CSV file listing every intermediate certificate trusted by Apple, Microsoft, or Mozilla. To find out who operates an intermediate certificate, you can look up the fingerprint in the ‘SHA-256 Fingerprint’ column, and then consult the ‘Subordinate CA Owner’ column, or if that’s empty, the ‘CA Owner’ column. - The CCADB’s
CAInformationReport, which lists the CAA domains and problem-reporting instructions for a subset of CAs. - For CAs not listed in the
CAInformationReport, the information comes from the CA’s Certificate Policy (CP) and Certificate Practice Statement (CPS), a pair of documents that describe how the CA is operated. The URL of the applicable CP and CPS can be found inAllCertificateRecordsSection 1.5.2 of the CPS contains problem-reporting instructions, and Section 4.2 of either the CP or CPS lists the CAA domains.
In a few cases, I’ve manually curated the data to be more helpful. The most notable example is the Amazon Certificate Manager (ACM). When you get a certificate through ACM, it’s issued by DigiCert from a white-label intermediate certificate with ‘Amazon’ in its name, similar to Cloudflare. However, Amazon has gone several steps further than Cloudflare in white labelling:
- To authorize ACM certificates, you put amazon.com in your CAA record, not digicert.com.
- Amazon operates its own root certificates, which have signed the white-label intermediates operated by DigiCert. This is highly unusual. Recall that the DigiCert-operated Cloudflare intermediate is signed by a DigiCert-operated root, as is typical for white-label intermediates.
If you look up one of Amazon’s intermediates in AllCertificateRecords, it will say that it is operated by DigiCert. But due to the extreme level of white labelling, I think telling users that ACM certificates were issued by ‘DigiCert’ would cause more confusion than saying they were issued by ‘Amazon’. So here’s what SSLMate’s Certificate Transparency Search API returns for an ACM certificate:
{
"id":"3837618459",
"tbs_sha256":"9c312eef7eb0c9dccc6b310dcd9cf6be767b4c5efeaf7cb0ffb66b774db9ca52",
"cert_sha256":"7e5142891ca365a79aff31c756cc1ac7e5b3a743244d815423da93befb192a2e",
"dns_names":["1.aws-lbr.amazonaws.com","amazonaws-china.com","aws.amazon.com", ...],
"pubkey_sha256":"8c296c2d2421a34cf2a200a7b2134d9dde3449be5a8644224e9325181e9218bd",
"issuer":{
"friendly_name":"Amazon",
"website":"https://www.amazontrust.com/",
"caa_domains":["amazon.com","amazontrust.com","awstrust.com","amazonaws.com","aws.amazon.com"],
"operator":{"name":"DigiCert","website":"https://www.digicert.com/"},
"pubkey_sha256":"252333a8e3abb72393d6499abbacca8604faefa84681ccc3e5531d44cc896450",
"name":"C=US, O=Amazon, OU=Server CA 1B, CN=Amazon"
},
"not_before":"2022-06-13T00:00:00Z",
"not_after":"2023-06-11T23:59:59Z",
"revoked":false,
"problem_reporting":"Send email to revoke@digicert.com or visit https://problemreport.digicert.com/"
}As you can see, friendly_name and website refer to Amazon. However, the problem_reporting field tells you to contact DigiCert, and the operator field makes clear that the issuer is really operated by DigiCert.
I’ve overridden a few other cases as well. Whenever a certificate issuer uses a distinct set of CAA domains, I override the friendly name to match the domains. My reasoning is that CAA and Certificate Transparency are often used in conjunction — a site operator might first publish CAA records and then monitor Certificate Transparency to detect violations of their CAA records. Or, they might first use Certificate Transparency to figure out who their CAs are, and then publish matching CAA records, thus ensuring consistency between CAA and Certificate Transparency provides the best experience. In fact, the CA names that you see on SSLMate’s CAA Record Helper are the exact same values you can see in the friendly_name field.
If you’re looking for a certificate monitoring solution, consider Cert Spotter, which notifies you when certificates are issued for your domains, or SSLMate’s Certificate Transparency Search API, which lets you search Certificate Transparency logs by domain name.
Andrew Ayer (Twitter, Mastodon) is a software engineer who works on security, usability, networking, and cryptography. He’s the bootstrapped founder of SSLMate, which makes it easy to obtain and monitor SSL certificates, and DNS Helper, which helps your customers add DNS records so you don’t have to.
This post was originally published on Andrew’s blog.
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.