(2 votes, average: 5.00 out of 5, rated)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

July 30, 2024 0

What Is a Certificate Authority List and Where Can I Find One?

in Hashing Out Cyber Security

PKI industry expert Ryan Hurst estimates that there are around 85 CAs, a little more than a handful of which “account for 99% of all certificate issuance on the web.” Do you know who these CAs are or where to find a list of root certificate authorities?

Publicly trusted certificate authorities (CAs) make sending and receiving data securely over the Internet possible. A certificate authority list is a compilation of these entities’ trusted roots and typically includes commercial names like DigiCert, Sectigo, and government entities such as the U.S. Federated Public Key Infrastructure (US FPKI).

But where do you find a certificate authority list? How and what are they used for? We’ll start by exploring individual lists of trusted certificate authorities and then wrap things up by answering these and other frequently asked questions (FAQs).

Let’s hash it out.

3 Common Certificate Authority Lists (and Where to Find Them)

Wondering what a list of trusted certificate authorities looks like and where to find them? Let’s start with exploring where to find three of the most common.

Certificate Authority List #1: Chrome Root Store

Another popular list of certificate authorities is operated by Google’s Chromium Project. The Google Root Store, guided by the Chrome Root Program Policy, has a list of active CAs that Google trusts for connections in its Chrome browser.

Google Root Store is currently on version 16 as of the writing of this article:

But where can you find that info in your Chrome browser?

• Open a new window in your Chrome web client.
• Navigate to chrome://system.
• Hit the Expand button next to chrome_root_store in the left-hand column (as shown in the screenshot below).

There, you’ll see a complete list of all the CAs Google trusts along with their hash values.

Certificate Authority List #2: Mozilla Root Store

Next, let’s take a quick look at Mozilla’s Root Store for its Firefox browser. This root store includes a list of CA Owners and their specific root certificates. You have multiple options for actions you can take for individual root CAs listed: view, import, export, edit trust, delete or distrust.

The list of certificate authorities trusted by Mozilla is available through the Firefox browser and is maintained in adherence with the Mozilla Root Store Policy. You can find it by:

• Navigating to Settings in the main menu.
• Selecting Privacy and Security in the left-hand navigation bar.
• Scrolling down to Security and finding the sub-section labeled “Certificates.”
• Click View Certificates and select the Authorities tab.

You also can access Mozilla’s Included CA Certificate List through the Mozilla Wiki page, which includes .txt and .csv files of both TLS and non-TLS use cases.

Certificate Authority List #3: Windows

Looking for a list of certificate authorities trusted by Microsoft? You can find the Microsoft Trusted Root Program on the Microsoft website. (This is what Windows OSes and the Microsoft Edge browser use.)

If you’re a Windows user, you can look at your machine’s operating system (OS) to see the list for yourself:

• Click on the Start menu.
• Type MMC into your run bar.
• Select Run as Administrator.

This will pull up your MMC Console, where you can add the Certificates Snap-In and view the trusted CAs listed there. Here’s a quick screenshot example of the list of trusted certificate authorities you’ll find when you access the MMC Console this way:

Where to Find Other Certificate Authority Lists

These three lists aren’t the only ones available. The certificate authorities that own and operate the root CAs also typically host lists of their certificate authorities on their websites. For example:

• DigiCert’s DigiCert’s Root and Intermediate Certificates List
  • QuoVadis’ List of Root and Issuing Certificate Authorities
  • Thawte’s List of Root Certificate Authorities
• GlobalSign’s Root Certificates List and Intermediate CA Certificates List 
• Sectigo’s List of Root and Intermediate Certificate Authorities
• U.S. Department of the Treasury’s CRLs and Certificates List

There are also third parties that host lists of root CAs they trust for their software applications and other systems. Some examples of these other certificate authority lists include:

• Apple Trust Store (current and past lists)
• Adobe Approved Trust List
• CheckTLS’s Trusted Root Certificate Authority List
• eIDAS List of Trusted Lists
• MATTER’s Distributed Compliance Ledger (DCL)
• PKI Consortium’s List of Trust Lists

3 Tools You Can Use to Put Certificate Authority Lists to Work

Okay, let’s assume you’ve got access to these lists now. So, how can you use them?

Mozilla Certdata

An app like mozilla_certdata parses Mozilla’s source certdata.txt file for such root CA information while considering trust records. However, that’s not always ideal because of some of the previously mentioned concerns.

Certifi

You can also use a tool like Certifi, a software library that simplifies extracting CA bundle data (i.e., root and intermediate CAs) from Mozilla’s Included CA Certificate List. It has packages that work with multiple languages, such as Python, Ruby, Golang (Go), etc. This makes verifying CA certs against Mozilla’s list easier.

MKCert API

MKcert is another potentially useful tool that pulls and parses Mozilla’s trusted list. However, this open-source tool is different in that it allows you to use an API to determine which CAs you want to trust (not just blindly by whatever Mozilla or other browsers say) and download trust files that include your specified CAs.  

Now you know where to find all of these independent lists and what tools you can employ to use them. But isn’t there a comprehensive single resource that can provide you with a list of certificate authorities in one place? We’ve got you covered.

The Common CA Database (CCADB): The Holy Grail of CA Lists

The Common CA Database is a one-stop resource for Root Store operators like Microsoft, Mozilla, and Google. It’s a centralized repository where CAs like DigiCert, Sectigo, Visa, Amazon, and others can publish information about their root CAs to ensure those Root Store operators get consistent, current, and accurate information.

Tracking down each CA’s root and ICA certificate information would be annoying and tedious. To simplify this process, the CAs share their lists with this centralized repository. This makes the CCADB the most comprehensive list of certificate authorities out there, as it even includes a list of revoked CAs as well.

Part of the CCADB Policy’s General Provisions states that CA Owners must keep the information for their organizations, root CA and subordinate CA certificates current. You can view the CA certificates used in Microsoft’s and Mozilla’s Root Stores in the CCADB.

How Many CAs Are Involved in the CCADB?

As far as I can tell, virtually all of them. The CCADB includes any CAs with roots or intermediate CAs included in the lists of several notable Root Store operators (think Apple, Google Chrome, Microsoft, and Mozilla Firefox).

For example, section 2.1.1 of Apple’s Root Certificate Program Policy Requirements states: “Effective April 1, 2022, CA providers must disclose in the CCADB all CA Certificates which chain up to their CA Certificate(s) included in the Apple Root Program.”

You can download the “All Certificate Records Report” list (a snippet of which is pictured above) of the 8,600+ intermediate and root CA certificates that have been submitted to the CCADB. Just keep in mind that this list includes a mix of revoked and non-revoked trust chain certificates. So be careful about how you use this information.

Certificate Authority List Use Cases

Now that we know what these different lists of certificate authorities are and where to find them, it’s time to explore what to do with them.

Who Typically Uses These Lists and Why?

Technically, anyone can access lists of certificate authorities online. Each CA typically has a list(s) of individual roots and/or intermediate certificates that it publishes on its website. (We’ll explore examples of those lists a little later in the FAQs section.)

These lists are handy for:

• Researchers who use the data for their studies and analyses.
• Software developers who use them to create apps that interact with WebPKI and specific device operating systems.
• PKI engineers and IT admins who need to ensure their software apps and network are using valid certificates (or if they need to import them).

Where Can You Use These Lists?

Certificate authority roots should be included in all hardware and software applications that support or rely on them. This includes your browsers, operating systems, web clients, and more.

Warning: Use the Right List for the Right Task

Are certificate authority lists one-size-fits-all solutions? No. Use the appropriate root CAs for their intended uses. Otherwise, things aren’t going to end well.

This is why, in addition to the all-encompassing list that includes all root and intermediate CAs, the CCADB also provided more targeted lists geared for specific purposes. For example, the CCADB Resources page includes the following lists:

• Code Signing Root CAs: These lists are curated for the express purpose of providing trusted certificates for code signing use cases.
• Email (S/MIME) Root CAs: This list is intended to verify certificates that are used for email digital signatures and encryption. An example is Google’s List of Trusted Certificate Authorities for S/MIME.
• Server Authentication Root CAs: This list is intended for use for SSL/TLS authentication in the SSL/TLS handshake process in order to establish secure, encrypted connections.

CA Lists Aren’t Meant for Cross Purposes

Why does it matter whether you’re using S/MIME roots or Server Authentication roots? According to Mozilla, root store misuse is a big concern for several key reasons:

• Each CA on a specific list is evaluated based on set criteria for its specific usage. For example, S/MIME roots have different procedures, controls, and audit criteria from those for SSL/TLS and code signing. This means you’ll be using the root certificates for unintended purposes. 
• Using a root store list for unintended purposes leaves you vulnerable. Mozilla describes misusing root stores as being “no different than failing to validate a certificate at all.”
• You may wind up trusting untrusted CAs. If an app developer tries to use scripts to parse data and may inadvertently end up trusting certificates that haven’t been assessed or have been explicitly distrusted. Either way, it’s bad news.

Mozilla instead recommends using the certificate lists provided by the CCADB:

“We strongly encourage application developers to ensure that the list of root certificates that they are using in their applications have been curated for their use case. Additionally, application developers should only use the Mozilla/NSS root store for TLS or S/MIME by using the links provided on the CCADB Resources page that list the certificates in the Mozilla/NSS root store according to the trust bits (key usage) they are curated for.”

In summary: If you’re going to use one of these lists, be sure to only do so for that specific list’s intended uses and applications.

Frequently Asked Questions (FAQs) About Lists of Certificate Authorities

Now, some of you might be new to Hashed Out or may have found this article because you’re trying to learn what a certificate authority list is and how it’s used. Knowing this, let’s answer some common questions people ask about certificate authority lists.

What Is a Certificate Authority List?

A certificate authority list is a roster of publicly trusted root certificate authorities that help form the “chain of trust” that companies rely on to secure public and/or private networks. They sign the issuing CAs that provide digital certificates that make authentication, encryption, and data integrity protection possible.

Root CAs are the MVPs of data security on the internet because, without them, there wouldn’t be secure connections on open networks.  We’d still be still holding clandestine face-to-face meetings to exchange private keys to exchange encrypted data.

Web browsers, operating systems, software applications, and many other systems use lists of certificate authorities to verify whether certificates are trusted and can be relied on for validation. 

Do Certificate Authority Lists Contain Info on Private CAs?

Typically, when someone refers to a certificate authority list, they’re talking about publicly trusted root CAs. I’ve talked about public and private CAs before, but to quickly recap:

• Publicly trusted CAs provide endpoint certificates that enable you to trust third-party website connections, apps, and emails.
• Private CAs allow you to issue certificates for trusted devices, users, files, apps, services, and emails within your network.

There’s no reason or way to track private CAs — it’s virtually impossible, impractical, and unnecessary since they’re not used publicly. But organizations should have internal systems in place to track their lists of their private PKI certificate authorities (roots and ICAs alike) as well.

What Comprises a Certificate Authority List?

A certificate authority list is an inventory of root CAs and, sometimes, the intermediate CA (ICA) certificates that “chain” back to them. (More on root and intermediate CAs a little later.) Together with endpoint certificates, these entities form what’s known as the Chain of Trust or PKI Trust Chain.

Each list of certificate authorities varies; some are relatively comprehensive, while others are pretty basic. But these lists typically the entries include some or all of the following information:

• The names of each certificate authority
• Categorization as a root or intermediate CA
• Certificate validity dates
• Serial numbers for the certificates
• SHA1 and SHA-256 fingerprints

Who Maintains These Lists?

Many individual lists of certificate authorities are maintained by the CAs themselves, while others are maintained by separate groups that trust different certificate providers (i.e., Trust Stores).

In Which Formats Are CA Lists Available?

These lists are typically a privacy-enhanced message (PEM) that’s available in either a .txt or .csv file format. These files typically contain a bunch of gibberish-looking data book-ended between header and footer messages (e.g., —–BEGIN CERTIFICATE—– and —–END CERTIFICATE—–), much like you see when you complete a certificate signing request (CSR).

What Qualifies a CA for Inclusion in a Certificate Authority List?

For inclusion in specific Stores’ lists of trusted certificate authorities, the answer depends on the provider. For example, Google Chrome’s Root Program Policy states that CA certificates must meet certain qualifiers to be included in its Root Store:

“The selection and ongoing inclusion of CA certificates is done to enhance the security of Chrome and promote interoperability. CA certificates that do not provide a broad service to all browser users will not be added to, or may be removed from the Chrome Root Store. CA certificates included in the Chrome Root Store must provide value to Chrome end users that exceeds the risk of their continued inclusion.”

Regarding CCADB participation, CA Owners may be required to submit their information to the database by the policy requirements of Trust Stores such as Chrome or Firefox. The database contains a comprehensive record of both root and intermediate certificate authorities.

How Often Are These Lists Updated?

The answer varies. For example, the CCADB’s Policy specifies that a CA must update its subordinate CA information within seven calendar days if a certificate is revoked or there are other changes.

Regarding the root certificates, Trust Store Operators must first verify data before a root CA can be changed or revoked.

What Are Intermediate and Root CAs?

Root CAs are at the heart of public key infrastructure. Without them, it simply wouldn’t exist. ICAs serve as a buffer between those roots and the endpoint certificates you use to secure your website, users, devices, etc.

A root CA issues an ICA, which then issues endpoint certificates. This process creates a crucial layer of separation between the root and the endpoint entities you install on web servers and other devices.

Let’s consider the SSL/TLS certificate we use here at TheSSLStore.com to secure our website:

In this case, the certificate on our site (labeled thesslstore.com) “chains” back to the intermediate CA certificate (DigiCert EV RSA CA 02) that issued it. That subordinate CA then “chains” back the root CA (DigiCert Global Root 52) that digitally signed it. The following screenshot illustrates this so-called “Chain of Trust”:

Here’s a breakdown of how this hierarchical relationship works and which certificate is responsible for signing each component of the trust chain:

How Often Are Intermediates and Roots Created & Updated?

The answers vary based on the CA. I reached out to Corey Bonnell, Industry Technology Strategist at DigiCert for more specifics:

“Generally, new roots are created every few years before the expiration of existing root certificates to ensure that new roots gain ubiquity prior to being used for issuance. The frequency of issuance for intermediates varies between CAs. For some smaller CAs, intermediate CA creation might be done less than once a year, whereas for larger CAs (such as DigiCert), new intermediates are created every week.”

Interesting. So, are there any specific industry requirements or limitations impacting this? Bonnell says not now, but that may change in the future:

“The CA/Browser Forum currently has no policies on root/intermediate CA creation frequency, but several browser root program representatives have stated that they intend to limit the period where specific root certificates are trusted. When formal policies are put in place that restrict the lifetime, the frequency of root CA creation will increase.”

Shorter ICA Lifespans = Reduced Exposure Risks

The idea is that shortening an ICA’s lifecycle means better security, as there is less exposure in the event of a key compromise.

In one sense, that’s true. The thought is that by having shorter ICA lifespans, you reduce the extent of the damage you’d suffer from said compromise because its private key wouldn’t be in use as long. However, the reality is that it doesn’t matter whether your ICA is valid for a few months or three years — if it gets compromised, there will be repercussions regardless.

The only way to ensure that your ICA (or any digital certificate, for that matter) doesn’t become compromised is to properly secure your network and servers and adhere to private key and certificate management industry standards and best practices. For example, safeguard your private keys by storing them securely using hardware security modules (HSMs).

Bonnell suggests that the impact of ICA compromises can be reduced by implementing “robust key destruction or archiving controls” for CA keys. We’ve seen an industry move toward shortening the lifespan of ICA keys. For example, the CA/B Forum’s Code Signing Working Group (CGCWG) draft ballot (CSC-26) aims to require CAs to destroy or archive Timestamp Authority (TSA) private keys after 18 months.

What’s the Difference Between a Certificate Authority List and a Certificate Revocation List?

Is a certificate authority list the same as a certificate revocation list (CRL)? No. Although both have the words “certificate” and “list” in their names, these lists serve different purposes.

• A certificate authority list is generally a centralized log of entities that form the trust chains publicly trusted endpoint certificates rely on.
• A CRL is a list of certificates that have been revoked by those CAs prior to their expiration dates. (This can include endpoint certificates and ICAs but not roots.) This is something that gets shared with a user’s connecting browser. Each publicly trusted CA must host its own certificate revocation list, making the online certificate status protocol (OCSP) revocation indicator method optional.

How do you use certificate authority lists within your development processes and network? Share your thoughts in the comments below.

• #Certificate Authority List