Not sure how to become a certificate authority? We’ll break all of that down for you in addition to explaining the differences and uses of public and private CAs
Trying to figure out how to become a certificate authority (CA) is something that we receive a surprising number of questions about. And it’s not because people are just bored — it’s because they realize the value and control having their CA offers their organizations’ PKI environments.
Certificate authorities play critical roles in organizational security. Some CAs help you increase security over the internet while others are great for securing internal networks and resources. Understanding the role of each CA and how you can use them will help you go a long way.
In this article, we’ll explore what’s involved when you want to create your own certificate authority — both in terms of public CAs and private CAs. Let’s start by addressing the differences between the two types of certificate authorities. We’ll then bring it all home by explaining why setting up a private CA is the best option for most business applications.
Let’s hash it out.
What’s the Difference Between Becoming a Public CA or a Private CA?
A public certificate authority (public CA) is a third party that’s inherently trusted by browsers, clients, operating systems, and applications to issue digital certificates you can use in public channels. This differs from a private certificate authority (private CA or internal CA), which is an internal entity that issues digital certificates that are only known and trusted within the confines of your organization’s internal network and IT environment. Basically, the first secures resources on the public-facing internet whereas the second secures resources for your internet network.
If a user outside of your internal network visits a website that you’re securing using a private CA certificate, they’ll get a message like this:
There are many differences between public and private CAs, but what really differentiates them, at their core, is the ability to establish trust over open networks (i.e., insecure internet connections). But it should come as no surprise that trust requires identity. Just like you wouldn’t let a stranger walk into your home, trust on the internet also requires identity.
Digital certificates are a form of digital identity on the internet. They prove you’re really you and not an imposter. In this context, a public CA is like federal passport officials, whereas a private CA is more like your company’s human resources team.
- A public CA issues certificates to individuals whose identities they’ve verified through tons of documentation and in-depth vetting. Like a passport, they’re valid virtually everywhere because they’re inherently trusted by applications, operating systems, and browsers.
- A private CA also issues certificates and manages everything relating to their lifecycles (like how HR helps new employees get their ID badges and employee numbers). But these forms of identity are only valid within your business’s environment and aren’t trusted by external parties.
Inherent trust is something that takes a long time and a lot of resources to build. But how do public CAs achieve that kind of trust with external entities?
Public CAs Create a Chain of Trust That External Entities Trust Automatically
Every certificate that public CAs issue can be “chained” (traced) back to a root certificate. It’s like a digital certificate’s equivalent of genealogy — the certificate can trace it back through its “family tree” to the original CA root that issued it. This is what makes a certificate publicly trusted.
If you were to look at the chain of trust using a literal tree as an example:
- Root CA certificates represent the tree’s roots. Root CAs only issue a handful of these self-signed certificates, so they do everything they can to keep them secure. These certificates sign intermediate certificates to establish trust and give them the ability to issue trusted certificates in their places.
- Intermediate CA certificates represent the trunk and larger branches. Intermediate CAs are basically a buffer between root certificates and endpoint certificates. They protect the root key and can be revoked more easily than their trusted root counterparts.
- Endpoint certificates represent the smaller branches and leaves. Intermediate CAs issue these certificates to domains, individuals, and organizations for many purposes.
This chain of trust makes it possible to store your root CA keys offline and only bring them out to use when necessary. This ensures these special keys stay secure and don’t fall prey to compromise by third parties.
Private CA Certificates Have a Chain of Trust That’s Limited to Your Internal Network
Like public CAs, private CAs also have a chain of trust that can be two or three (or more) levels. But because internal CAs issue certificates that are used only within your organization’s internal environment, the private CA doesn’t need to be publicly trusted. This is fine so long as you’re only using these private CA certificates to secure non-public sites, web apps, and services.
Common Use Cases: When You Need a Private vs Public CA
So, how do you know when you need a private vs public CA? Public CA certificates can be used for many public channel applications:
Private certificates, on the other hand, have many uses for enterprises’ non-public environments:
- Enabling users to authenticate to internal systems and sites,
- Securing internal resources and services,
- Securing your devops build servers and testing environments, and
- Deployment for IoT devices.
How to Become a Trusted Certificate Authority (Public CA)
Frankly, this process is a lot harder to accomplish than one might think. It requires vast amounts of time, resources, and money. There are many different requirements you have to meet as a minimum, both initially and on an ongoing basis. There are platform-specific requirements as well as audit-related criteria that are crucial for compliance.
Even if you manage to create your own publicly trusted CA, you’d then still have the issue of figuring out how to gain market share in an established marketplace. Out of the hundreds of certificate authorities that exist globally, only a handful of commercial CAs are responsible for issuing the overwhelming majority of publicly trusted certificates in use globally.
DigiCert, Sectigo, and IdenTrust (Let’s Encrypt) are among the world’s largest public CAs, and you’ll be trying to compete against their decades of experience and longstanding reputations within the industry. As of June 29, 2021, W3Techs.com reports that of the top 10 million websites they monitor:
- 45% use IdenTrust (52.7% of the SSL CA market share),
- 16.5% use DigiCert (19.5% of the SSL CA market share), and
- 14.3% use Sectigo. (6.8% % of the SSL CA market share).
With all of this in mind, let’s go over some of the requirements of how to become a publicly trusted certificate authority (and why it’s typically not an option for most businesses).
You Must Meet Many Criteria From Different Operating Systems & Browsers
Your root and/or intermediate certificates must be included in the trust stores on multiple platforms to be publicly trusted. Some platforms call them trust stores while others call them root stores — it’s just a difference of semantics. To be included in these stores, whichever they’re called, your CA must meet a series of initial requirements as well as ongoing program requirements.
We’ll give you a brief overview of each certificate program or root store and provide links to where you can find more in-depth information.
Microsoft Root Certificate Program
Microsoft’s Root Certificate Program is what makes it possible to distribute your trusted root certificates across various Windows OSes so applications can use them for reference. Windows uses certificate trust lists (CTLs) to store trusted and untrusted root certificates.
Apple Root Certificate Program
Apple’s Root Certificate Program enables you to store and distribute trusted root certificates across MacOS and iOS systems, Apple’s Safari browser and their Mail.app. Many of their CA Program requirements are based on audits and requirements from other organizations, including WebTrust and the CA/Browser Forum (CA/B Forum) — we’ll speak more to both of these organizations momentarily.
Chromium Project Root Certificate Program
The Chrome Root Program is Google Chrome’s version of the root programs offered by the other browsers and operating systems on this list. This root program is the set of requirements and policies for CAs to have their root certificates included in the Chrome Root Store. The processes and requirements for inclusion are similar to those that are required for the next type of root store we’re about to talk about…
Mozilla’s CA and Root Store Programs
Having your root CA known and recognized by the Mozilla CA Certificate program and Root Store Program is integral for trust with their products and apps. This root store holds trusted certificates so that they’re accessible to their browser applications and other software products.
The root policy requires CAs to at least be aware of what goes on in Mozilla’s Dev-Security-Policy forum to ensure they’re aware of changes relating to security policies and governance. Mozilla appointed a “CA Certificate Policy module owner” (and peers) to both maintain their policy and evaluate new CA requests.
Mozilla also runs the Common CA Database (CCADB) that their company, as well as other root store operators, utilize.
CA/Browser Forum Baseline Requirements
The CA/Browser Forum comprises dozens of publicly trusted CAs, browser platforms, and other security-related organizations. Their CA/B Forum Baseline Requirements outline the minimum standards certificate authorities must meet to qualify for public trust in several key areas, including:
WebTrust Principles and Criteria and Practitioner Guidance for CAs
WebTrust’s PKI Assurance Task Force publishes multiple principles and criteria, guidelines, and baseline audit frameworks that licensed third-party auditors use to assess CAs in multiple areas. (These auditors carry out audits for the Chartered Professional Accounts of Canada [CPA Canada]). They also provide principles and criteria for auditing registration authorities (RAs) as well. The WebTrust Task Force have published multiple frameworks and documents, including:
- Principles and Criteria for CAs,
- Engagement Applicability Matrix,
- Extended Validation SSL Certificates Framework,
- SSL Baseline with Network Security Framework,
- Code Signing Baseline Requirements (both for regular and EV certificates), and
- Registration Authorities Principles and Criteria.
You Must Invest Immense Resources (Time, Money & People) to Be Considered
Do you have piles of money lying around your office and oodles of free time to spare? If yes to the former, wanna share? And if your answer about whether you have loads of free time to spare is also yes, then you’re one lucky schmuck. But if your answer to either of these questions is no, then trying to establish your own public CA likely isn’t in the cards for you.
There’s no need to feel badly about that, though. As you learned in the previous section, becoming a publicly trusted CA requires many policy-related and technical hoops for you have to jump through to just be considered. And there is one important caveat worth mentioning: being considered for CA approval isn’t a guarantee. So, all of that time and energy could be for nothing if your…