Tips for web professionals

How to tell what certification authority issued a site’s SSL certificate

A green shield with a check mark on a blue field with question marks, signifying how to find an SSL certificate's Root CA

Not all SSL certificates are the same.

Most internet users, if they know to look for it, will see the lock in the browser’s address bar and leave it at that. Most of the time, it probably doesn’t actually matter, but given that SSL certificates are what the security of all transactions and online accounts is based, so when it matters, it really matters.

Most internet users are probably not aware that the security of their online transactions and accounts are dependent on a “chain of trust”—essentially the extended reputation of a handful of imminently trusted issuers of SSL certificates. The issuers—known as Certificate Authorities (CAs)—are essentially the guarantors of online. But how can you tell which of these companies is responsible for a given website’s SSL certificate? And does it even matter?

Why you would want to know what CA issued a certificate?

What is a CA?

Let’s back up to talk about what a CA is and describe the system used for ensuring the security of SSL certificates.

A CA, or Certificate Authority, is some entity that issues, signs, and stores certificates, such as SSL/TLS certificates. These entities are part of a limited number of providers who fulfill the technical requirements for becoming a Certificate Authority. In the world, there are only about 65 Certificate Authority (despite some erroneous reports that there are over 600 such entities).

Chain of trust

There are essentially four types of CAs:

  1. Root CAs
  2. Intermediate CAs
  3. Subordinate CAs
  4. Untrusted CAs

The first three of these CA types actually corresponds to a different point in the “chain of trust,” on which SSL certificate security relies.

The 65 or so Root Certificate Authorities that are recognized by browsers. In order to enable flexibility and scalability of this system, organizations trusted by these root CAs can be issued an intermediate certificate, which enables them to create certificates that rest on the authority of the root CA. These organizations trusted by root CAs are intermediate CAs. The root CA cryptographically “signs” the intermediate CA’s certificate to document that it’s lending its authority to that entity, who can then use this certificate to issue certificates for others.

A subordinate certificate is essentially a broader term for an intermediate certificate, meaning that a subordinate CA is not essentially different from an intermediate CA except that an intermediate CA generally refers to a subordinate CA that issues certificates to other third parties.

These subordinate and intermediate CAs then issue the actual SSL/TLS certificates used, for example, by websites using HTTPS. The final SSL/TLS certificate used by a website, then, will be signed by a certificate that’s signed by the Root CA. This is the “chain of trust.”

So long as the “chain of trust” can be traced back from a certificate to a Root CA, browsers will consider it reliable, display the lock in the address bar, and won’t display a warning to users. For most users, then, thanks to the chain of trust, there is no functional difference between a certificate signed by a Root CA and one signed by an intermediate CA.

Requirements for being a CA

There’s not necessarily one single way that CAs are certified as trustworthy across the world. Generally, if a CA is trusted by

In North America, almost all root CAs follow the “WebTrust” standards, whereas CAs in Europe are audited by the European Telecommunications Standards Institute (ETSI), and government CAs are often verified by the government in question.

Either way, these auditing programs ensure that root CAs follow some standard security practices that protect the security of the SSL/TLS certificates they issue.

However, whether or not a CA is “trusted” is dependent on the browser. No universal technical standard exists that tells browsers how to select CAs to include in their list of trusted CAs. In other words, each browser sets their own policies for approving CAs.

Who are the main CAs?

According to Digicert, these are the top 8 SSL certificate CAs, which account for nearly 75% of all certificate:

  • Comodo — 42.6%
  • Digicert — 15.3%
  • GoDaddy — 7.7%
  • GlobalSign — 4.9%
  • Digicert — 2.3%
  • StartCom — 0.9%
  • Entrust — 0.4%
  • Certum — 0.5%

Does a certificate’s CA matter?

Yes and no.

On the one hand, a certificate signed by one of the 65 or so trusted CAs is more than likely as safe as any other. What’s more, so long as the CA is trusted by your browser, you won’t see any indication when you visit a webpage of who the trusted root CA responsible for guaranteeing the security of the certificate is, but just the lock icon in the address bar. In that sense, it doesn’t matter, since most browsers and end users will consider that one trusted CA is as good as any other, and in many cases, that’s probably true.

On the other hand, as described above, the entire system of SSL/TLS certificates is based on trust. If the chain of trust of a certificate contains entities that users cannot actually trust to maintain the security and integrity of the SSL/TLS certificates, then absolutely, this matters.

Let’s take an extreme hypothetical to illustrate the point. If you are a vocal critic of Russia’s invasion of Ukraine living in Russia, you might be wary of exchanging financial information or passwords to your personal on a website with a certificate who’s root CA is owned by the Russian government.

But most cases are not nearly as dramatic. Some CAs may not be quite as up to snuff as you would want, and, of course, in some cases there won’t be any root CA and the certificate will be “self-signed.” Malicious websites might also exploit vulnerabilities in the certificate handling code that haven’t been patched yet and cause the lock icon to be displayed just as though there were a valid certificate behind it.

In these cases, a certificate’s CA absolutely does matter.

Besides these, maybe, situations, the fact that browsers need to have a list of trusted CAs, means that a certificate’s CA is of the utmost importance, even if it’s the browser itself that does the work of making sure that the CA is issued by an internationally recognized company rather than something made up by hackers.

How can you tell what CA issued a cert?

Where is information about a certificate’s CA stored in the certificate?

The structure of a certificate

The CA that issued a particular certificate is, first of all, indicated in the certificate file itself. This file is a .crt file that’s stored on the web server of a website.

These files use the X.509 standard, which mandates a particular format for the data contained in it.

This is the structure of the information in an X.509 certificate:

  • Version Number
  • Serial Number
  • Signature Algorithm ID
  • Issuer Name
  • Validity period
    • Not Before
    • Not After
  • Subject name
  • Subject Public Key Info
  • Public Key Algorithm
  • Subject Public Key
  • Issuer Unique Identifier (optional)
  • Subject Unique Identifier (optional)
  • Extensions (optional)
  • Certificate Signature Algorithm
  • Certificate Signature

The “Issuer name” is the part of this data that would indicate the CA.

How do you find a certificate’s CA in your browser?

Luckily, you don’t have to read any specific website’s .crt file yourself in order to find the CA that issued a certificate for a particular website—your browser reads and interprets the certificate and provides the information in a more readable way, if you know how to find it.

The exact process depends on the browser, but in most cases, you start by clicking the lock next to a URL for a website secured by SSL/TLS.

TLS or SSL certificates are extremely important for ensuring security online and their security is guaranteed by “chains of trust” that make it possible to trace back the signing of the certificate to one of a relatively restricted number of trusted root certificate authorities, or Root CAs.

The Root CA that signs a certificate is extremely important. The Root CA for an SSL certificate on a website you visit should be an entity that you trust. But because the ecosystem of SSL certificate CAs is complex, it’s hard for every individual user to trust every possible CA.

The result is that web users do not actually trust individual CAs—whether intermediary or root—at least not directly. Instead, they trust the browsers and the lists of trusted CAs they maintain.

For the vast majority of internet users, the appearance of a lock icon in a browser’s address bar is enough to trust that a website has properly implemented SSL and the information entered on that website is safe from eavesdroppers, in other words, that the website can be trusted with private data.

That’s why it’s sometimes important and necessary to look at what the Root CA of a website’s TLS / SSL certificate is.

In the grand scheme of things, though, it’s not reasonable that internet users trust or distrust individual CAs they have probably never heard of.

There should be some intermediary option between trusting all webpages that a browser displays a lock icon for, and looking up the certificate authority for the certificate.

For this, the only solution would be some kind of additional contextual information to help internet users evaluate the trustworthiness of a website.

Until then, either trusting the browser’s lock icon or looking up the Root CA who issued the certificate are the best options.

Protect your website’s users with an TLS / SSL certificate at Gandi