How to Become a Certificate Authority (Public vs Private)
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:
- Securing your website and email servers (website security certificates, i.e., SSL/TLS certificates),
- Digitally signing and encrypting emails (S/MIME certificates),
- Digitally signing code for software, testing, and IoT devices (code signing certificates),
- Enabling user authentication without passwords (client authentication certificates), and
- Digitally signing documents (document signing certificates).
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:
- SSL/TLS Baseline Requirements,
- Code Signing Baseline Requirements, and
- Network Security Requirements.
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 efforts ultimately fail.
Something else to keep in mind as well is that this doesn’t even include the money you’d have to invest in terms of your initial start-up and ongoing costs, some of which include:
- Secure storage devices, IT hardware, and other general infrastructure (and there are differences in cost when talking about on-prem hardware vs cloud),
- Staffing (salaries, benefits, and all the additional costs that go along with hiring humans),
- Education and training,
- Certificate validation-related costs (for organization validation [OV] and extended validation [EV] certificates),
- Research and development,
- Compliance audits and assessments, and
- Other ongoing costs.
Sure, you can cut costs by going the fully automated route like a certain nameless free CA… but then you’re limited in terms of what types of certificates you’re allowed to issue. (Obviously, you can’t issue OV and EV certificates if you don’t have the resources on hand to perform the necessary validation processes.)
Your Public Root CA Requires Significant Distribution Efforts
And still, even after all this, your work isn’t done. Before you can be a functioning CA, all devices have to be updated to include your root certificates. This requires the distribution of the certificate to achieve root ubiquity. As you can imagine, it’s a major process to get all the browsers, operating systems and applications to trust your certificates and isn’t something that happens overnight.
Achieving root ubiquity can potentially take years to complete unless you cross-sign your certificates to create alternate trust paths (i.e., capitalize on an existing CA’s trusted roots). But cross signing is a practice that’s becoming less common and isn’t easy (as we saw with Let’s Encrypt’s cross signing challenges at the beginning of this year).
Simply Put, the Juice Isn’t Worth the Squeeze
Although becoming a publicly trusted CA might sound great on its face, it requires so much effort that there’s no real advantage for most companies. Heck, even the U.S. federal government doesn’t want to deal with creating their own certificate authority! Instead, the U.S. government relies on a network of existing CAs who issue certificates to meet their needs.
The reality is that for what many companies actually need, simply purchasing certificates from an established CA will more than meet their needs for public applications. You can save significant time, money, labor, and other resources by simply purchasing public CA certificates from CAs like DigiCert or Sectigo.
If you’re someone who will still lie awake late at night dreaming about how to become a trusted certificate authority after reading all of this, then you might be a glutton for punishment and should keep reading ‘cause this next section is for you. But if you’re now interested in learning how to set up a certificate authority for your internal environment, then the rest of this article (after this next section) was written specifically with you in mind.
Why Becoming a Private CA Is a Better Option for Most Organizations & Enterprises
My colleague Mark recently published an article that looked at the process involved with creating your own private CA server. There are many reasons, including greater control and flexibility for securing your internal networks and services as well as simplifying authentication for your employees. Let’s review a few of them:
You Only Need to Distribute Your Root CA to Devices On Your Internal Network
You can breathe a sigh of relief in knowing that your root CA distribution is limited to network devices. Private CA certificates aren’t publicly trusted, so they won’t be used by external users, clients, operating systems or services. Therefore, you don’t have to go through all the rigmarole that public CAs do in terms of root ubiquity.
You Can Create Customize Certificate Profiles and Policies
When people think of digital certificate profiles, they typically think of traditional X.509 extensions. However, some managed PKI providers allow you to create custom certificate profiles to match anything you need to secure (more on that in my next point).
You Can Issue Certificates to “Things”
While public CA certificates are issued to public entities, private CA certificates can be used without requiring a public hostname/IP address or email address. This means you can issue public certificates for:
- Internal web apps and services,
- IoT devices,
- Virtual private networks (VPNS), and
- DevOps build servers and testing resources.
Private CA Server Control — 100% Yours (If You Want That Responsibility)
When you have your own private CA, another advantage is that you can choose to be in complete control of your IT infrastructure (i.e., your server hardware). Otherwise, you can rely on a managed CA to set up and manage all of that for you.
You Control Your Certificates’ Lifecycles From Start to Finish
There’s a lot of freedom that comes with being able to generate and sign certificates. You can create certificates at the drop of a hat, whenever and however you need them. Issuance? Revocations? You control all of it. And if you have the right API at your disposal, you can also have robust tools that make your certificate management processes easier.
How to Create Your Own Certificate Authority (Private CA)
Okay, now that we have that out of the way, let’s back to the topic of how to become a certificate authority. More specifically, let’s address what you need to know about how to set up a certificate authority within your organization (i.e., create a private CA).
You can choose one of two avenues of approach when it comes to setting up your private CA: you can build and host an internal CA server or use a third party (i.e., managed PKI or PKI-as-a-service). You can choose the hard path or the easy one — your choice or route will likely depend on your organization’s resources and the PKI knowledge and skills of your IT team.
Regardless of which method you choose, just remember to install your root certificates on all of your endpoint devices. If you don’t, then they’re not going to do you any good because nothing on your network will trust them.
Option 1: Build and Manage Your Private CA on Your Own (Internal CA)
This route is what’s going to give you the most control and customizability. That’s because you’re deciding what your platform and capabilities will entail because you’re literally building everything from the ground up.
But building a company-wide public key infrastructure isn’t cheap, and it’s definitely something you don’t want to half-ass. You need to ensure that you have the appropriate resources — knowledgeable and skilled workers, technologies, a secure space for everything to be housed, and a budget that covers all of these things — in place to ensure it’s a success and isn’t something that will give you nightmares.
If you’re a DIY kind of person and want to tackle this process yourself, here are some of the things you’ll need to know how to do.
Set Up the IT Infrastructure to Support Your Private CA Server, Certificate and Key
Before you can do anything else, you need to have the right people in place to select, set up, and manage all of your on-prem IT infrastructure. This counts everything from the servers and computers to the security hardware components that help to keep them all secure. Your CA server is responsible for handling everything relating to PKI such as certificate requests, signings, and revocations. Ideally, it should be a secure, dedicated server that isn’t used for other purposes (such as running other services).
Establish a Certificate Policy & Practice Statement That Guides Certificate Issuance and Management
This is an important step. In order to issue useful certificates, you need to have policy and documentation in place that ensure security. This information should outline many things, including:
- Processes and technologies that should be used to manage certificates and keys,
- Use cases and applications for creating certificates and keys,
- Who or what certificates can be issued to, and
- Who is responsible for implementing different functions and tasks.
Create Your Root CA Key and Certificate for Your Private PKI
You need a root CA certificate and key to get your internal CA up and running. It’s a best practice to create a root CA certificate, which you’ll then use sign your intermediate CA certificate, and then take the server with your root CA on it completely offline. You can then use the intermediate CA to issue your leaf endpoint certificates. Keeping that designated server offline and using the intermediate CA to issue certificates helps to protect the root CA.
Secure Your Private CA Cryptographic Keys
This next step is crucial. You need to keep your keys secure so they can’t become compromised yet they’re still available to the people who need access have access to them. This is where a hardware security module (HSM) can help.
Hardware security modules are tamper-resistant devices that enable secure cryptographic key storage. They keep your cryptographic keys secure so that bad guys can’t steal or use them. HSMs are similar to trusted platform modules (TPMs) in some ways but differ in terms of applications. (HSMs are useful for at-scale applications across an organization, whereas TPMs are device-specific.)
Public CAs and companies running internal CAs commonly use HSMs to keep their root CA keys secure. These devices are typically stored on premises in secure locations. If you had the ability to teleport into any of the major public certificate authorities’ IT facilities, you’d see that they keep these devices under lock and key, and many require multiple privileged users to use them.
However, these devices are pricy, which means they’re not ideal solutions for all organizations.
If you want to learn more about HSMs and TPMs, then stay tuned to Hashed Out. We’ll have a couple of articles coming out on those particular topics within the next few weeks.
Distribute Your Root CA to All Devices On Your Network
This next step in the process of how to become a certificate authority is easier said than done. Manual distribution of certificates is easy when you’re a small mom-and-pop outfit with just a handful of devices to manage. But when you’re a large enterprise with thousands of devices and, perhaps, spread across multiple geographic locations, this seemingly simple task becomes virtually impossible to handle.
This brings us to the next step…
Build Custom Integrations to Manage Your Private PKI
Now that you have your root CA set up and ready to rock, you need a convenient way to manage the lifecycles of all the digital certificates and keys that you’re going to create. You could use manual tracking methods like spreadsheets, but that’s a logistical nightmare that’s likely going to result in headaches down the road.
The other option is to use the Microsoft CA (Active Directory Certificate Services [AD CS]) API to manage your PKI internally. However, this requires building custom integrations to make Microsoft CA work with all of your network’s devices, applications, and other company systems. As you can imagine, this is challenging and requires a lot of expertise, time, and resources that you likely don’t have in house.
This brings us to the second option for creating a certificate authority for internal resources: use a third-party PKI platform or service provider.
Option 2: Use a Third Party to Manage Your Private CA (Managed PKI, or MPKI)
A managed PKI provider is a third-party company that specializes in helping organizations manage their public key infrastructures and private CAs. They have the people, policies, processes, and technologies in place to get your private CA up and running in no time.
Third-party MPKI providers offer many advantages for businesses that want their own private CAs, including:
- Knowledgeable and skilled experts. You no longer have to worry about hiring internal experts when they already have trained experts who are ready to help. MPKI providers handle your ongoing maintenance, security operations, and compliance for your private CA.
- Centralized, user-friendly certificate management dashboards. These pre-build certificate managers give you the certificate lifecycle visibility and control you need in a single pane of glass.
- Pre-defined certificate policies. You no longer have to worry about creating your own policies from scratch since they’ve already taken care of that for you. Having certificate policies in place helps you avoid unscheduled downtime and outages.
- Current software and IT infrastructure you don’t have to buy or manage. Although managed PKI doesn’t offer as much control as internally managing your private CA, there’s something to be said for enjoying the fruits of others’ labors.
Managed PKI is about gaining private CA benefits for your internal network without all of the headaches and costs that come along with internally managing one. Their team of experts ensures that all of your Ts are crossed and Is are dotted to ensure compliance and mitigate issues.
Why bother to reinvent the wheel when you can use an existing one that works great? Using a third party to manage your private CA is a great way to get the best of both worlds.
Final Thoughts on How to Become a Certificate Authority
Every business has its own unique needs, and I’m not about to presume to tell you what you need. Clearly, creating a public CA isn’t a worthwhile venture for most businesses in terms of ROI. The process requires way too much time and too many resources to make it worthwhile.
As you’ve learned, there are clear advantages to using a private CA. And while it’s nice to know that you have the option of building your own internal CA, in many cases, it’s better to rely on a trusted third party to help simplify the process.
Deciding between one versus the other should depend on your needs and the resources you can dedicate to your PKI. Either way, we hope you found this article informative and that it helps you make an informed decision.
5 Ways to Determine if a Website is Fake, Fraudulent, or a Scam – 2018
in Hashing Out Cyber SecurityHow to Fix ‘ERR_SSL_PROTOCOL_ERROR’ on Google Chrome
in Everything EncryptionRe-Hashed: How to Fix SSL Connection Errors on Android Phones
in Everything EncryptionCloud Security: 5 Serious Emerging Cloud Computing Threats to Avoid
in ssl certificatesThis is what happens when your SSL certificate expires
in Everything EncryptionRe-Hashed: Troubleshoot Firefox’s “Performing TLS Handshake” Message
in Hashing Out Cyber SecurityReport it Right: AMCA got hacked – Not Quest and LabCorp
in Hashing Out Cyber SecurityRe-Hashed: How to clear HSTS settings in Chrome and Firefox
in Everything EncryptionRe-Hashed: The Difference Between SHA-1, SHA-2 and SHA-256 Hash Algorithms
in Everything EncryptionThe Difference Between Root Certificates and Intermediate Certificates
in Everything EncryptionThe difference between Encryption, Hashing and Salting
in Everything EncryptionRe-Hashed: How To Disable Firefox Insecure Password Warnings
in Hashing Out Cyber SecurityCipher Suites: Ciphers, Algorithms and Negotiating Security Settings
in Everything EncryptionThe Ultimate Hacker Movies List for December 2020
in Hashing Out Cyber Security Monthly DigestAnatomy of a Scam: Work from home for Amazon
in Hashing Out Cyber SecurityThe Top 9 Cyber Security Threats That Will Ruin Your Day
in Hashing Out Cyber SecurityHow strong is 256-bit Encryption?
in Everything EncryptionRe-Hashed: How to Trust Manually Installed Root Certificates in iOS 10.3
in Everything EncryptionHow to View SSL Certificate Details in Chrome 56
in Industry LowdownA Call To Let’s Encrypt: Stop Issuing “PayPal” Certificates
in Industry Lowdown