智写AI

The SSL Certificate Issuer Field is a Lie

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 certificate authority 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 certificate authority 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:

C = IEO = BaltimoreOU = CyberTrustCN = Baltimore CyberTrust Root 3ABBE63DAF756C5016B6B85F52015FD8E8ACBE277C5087B127A60563A841ED8A C = USO = Cloudflare, Inc.CN = Cloudflare Inc ECC CA-3 6E5C90EB2E592F95FABF68AFAF7D05C53CBD536EEE7EE2057FDE63704F3E1CA1 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 certificate authority, and Baltimore is a
city.

In reality, both DoorDash’s certificate and the intermediate certificate
were issued by DigiCert, a name which 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-labeling
is common in the certificate industry, since it lets companies
appear to be CAs without the expense of operating a CA.

Sidebar: 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 certificate authority. 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, who acquired
GTE‘s certificate
authority subsidiary (named CyberTrust) in 2000, which they then sold to
a company named Betrusted in 2003, which merged with TruSecure in 2004,
who rebranded back to CyberTrust, which 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 certificate authority, 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 which 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 correct contact information for requesting revocation.

As of this month, 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/"
}

(Here’s the API query)

Note the following fields:

  • The friendly_name field contains “DigiCert”, not “Cloudflare”. This field is useful for displaying to humans.
  • The caa_domains field 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 operator field contains details about the company which 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_reporting field 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
    AllCertificateRecords
    report, 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 CAInformationReport, the information comes from the CA’s Certificate Policy (CP)
    and Certificate Practice Statement (CPS), a pair of documents which describe how the
    CA is operated. The URL of the applicable CP and CPS can be found in AllCertificateRecords.
    Section 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 Amazon Certificate Manager. 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-labeling:

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-labeling, 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 CT 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/"
}

(API query)

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 certificate authorities are, and then publish matching CAA records.
Thus, ensuring consistency between CAA and CT provides the best experience.
In fact, the certificate authority 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.


Source link