What\u2019s the Difference Between Becoming a Public CA or a Private CA?<\/h2>\n\n\n\n
A public certificate authority<\/a> (public CA)<\/strong> 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)<\/strong>, which is an internal entity that issues digital certificates that are only known and trusted within the confines of your organization\u2019s internal network and IT environment. Basically, the first secures resources on the public-facing internet whereas the second secures resources for your internet network.<\/p>\n\n\n\n If a user outside of your internal network visits a website that you\u2019re securing using a private CA certificate, they\u2019ll get a message like this:<\/p>\n\n\n\n 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\u2019t let a stranger walk into your home, trust on the internet also requires identity.<\/p>\n\n\n\n Digital certificates are a form of digital identity on the internet. They prove you\u2019re 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\u2019s human resources team.<\/p>\n\n\n\n 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?<\/p>\n\n\n\n Every certificate that public CAs issue can be \u201cchained\u201d (traced) back to a root certificate. It\u2019s like a digital certificate\u2019s equivalent of genealogy \u2014 the certificate can trace it back through its \u201cfamily tree\u201d to the original CA root that issued it. This is what makes a certificate publicly trusted.<\/p>\n\n\n\n If you were to look at the chain of trust using a literal tree as an example:<\/p>\n\n\n\n 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\u2019t fall prey to compromise by third parties.<\/p>\n\n\n\n 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\u2019s internal environment, the private CA doesn\u2019t need to be publicly trusted. This is fine so long as you\u2019re only using these private CA certificates to secure non-public sites, web apps, and services.<\/p>\n\n\n\n So, how do you know when you need a private vs public CA? Public CA certificates can be used for many public channel applications:<\/p>\n\n\n\n Private certificates, on the other hand, have many uses for enterprises\u2019 non-public environments:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Even if you manage to create your own publicly trusted CA, you\u2019d 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.<\/p>\n\n\n\n DigiCert, Sectigo, and IdenTrust (Let\u2019s Encrypt) are among the world\u2019s largest public CAs, and you\u2019ll be trying to compete against their decades of experience and longstanding reputations within the industry. As of June 29, 2021, W3Techs.com<\/a> reports that of the top 10 million websites they monitor:<\/p>\n\n\n\n With all of this in mind, let\u2019s go over some of the requirements of how to become a publicly trusted certificate authority (and why it\u2019s typically not an option for most businesses). <\/p>\n\n\n\n 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 \u2014 it\u2019s just a difference of semantics. To be included in these stores, whichever they\u2019re called, your CA must meet a series of initial requirements as well as ongoing program requirements.<\/p>\n\n\n\n We\u2019ll give you a brief overview of each certificate program or root store and provide links to where you can find more in-depth information.<\/p>\n\n\n\n Microsoft\u2019s Root Certificate Program<\/strong><\/a> 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.<\/p>\n\n\n\n Apple\u2019s Root Certificate Program<\/strong><\/a> enables you to store and distribute trusted root certificates across MacOS and iOS systems, Apple\u2019s 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) \u2014 we\u2019ll speak more to both of these organizations momentarily.<\/p>\n\n\n\n The Chrome Root Program<\/strong><\/a> 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…<\/p>\n\n\n\n Having your root CA known and recognized by the Mozilla <\/strong>CA Certificate program<\/strong><\/a> and <\/strong>Root Store Program<\/strong><\/a> is integral for trust with their products and apps. This root store holds trusted certificates so that they\u2019re accessible to their browser applications and other software products. <\/p>\n\n\n\n The root policy requires CAs to at least be aware of what goes on in Mozilla\u2019s Dev-Security-Policy forum<\/a> to ensure they\u2019re aware of changes relating to security policies and governance. Mozilla appointed a \u201cCA Certificate Policy module owner\u201d (and peers) to both maintain their policy and evaluate new CA requests. <\/p>\n\n\n\n Mozilla also runs the Common CA Database (CCADB)<\/a> that their company, as well as other root store operators, utilize.<\/a><\/p>\n\n\n\n The CA\/Browser Forum comprises dozens of publicly trusted CAs, browser platforms, and other security-related organizations. Their CA\/B Forum Baseline Requirements<\/strong><\/a> outline the minimum standards certificate authorities must meet to qualify for public trust in several key areas, including:<\/p>\n\n\n\n WebTrust\u2019s PKI Assurance Task Force publishes multiple principles and criteria, guidelines, and baseline audit frameworks<\/a> 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:<\/p>\n\n\n\n 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\u2019re one lucky schmuck. But if your answer to either of these questions is no, then trying to establish your own public CA likely isn\u2019t in the cards for you.<\/p>\n\n\n\n There\u2019s 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\u2019t a guarantee. So, all of that time and energy could be for nothing if your efforts ultimately fail.<\/p>\n\n\n\n Something else to keep in mind as well is that this doesn\u2019t even include the money you\u2019d have to invest in terms of your initial start-up and ongoing costs, some of which include:<\/p>\n\n\n\n Sure, you can cut costs by going the fully automated route like a certain nameless free CA\u2026 but then you\u2019re limited in terms of what types of certificates you\u2019re allowed to issue. (Obviously, you can\u2019t issue OV and EV certificates if you don\u2019t have the resources on hand to perform the necessary validation processes.)<\/p>\n\n\n\n And still, even after all this, your work isn\u2019t 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\u2019s a major process to get all the browsers, operating systems and applications to trust your certificates and isn\u2019t something that happens overnight.<\/p>\n\n\n\n Achieving root ubiquity can potentially take years<\/em> to complete unless you cross-sign your certificates to create alternate trust paths (i.e., capitalize on an existing CA\u2019s trusted roots). But cross signing is a practice that\u2019s becoming less common and isn\u2019t easy (as we saw with Let\u2019s Encrypt\u2019s cross signing challenges<\/a> at the beginning of this year).<\/p>\n\n\n\n Although becoming a publicly trusted CA might sound great on its face, it requires so much effort that there\u2019s no real advantage for most companies. Heck, even the U.S. federal government doesn\u2019t want to deal with creating their own certificate authority<\/a>! Instead, the U.S. government relies on a network of existing CAs who issue certificates to meet their needs.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n If you\u2019re 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 \u2018cause this next section is for you. But if you\u2019re 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.<\/p>\n\n\n\n My colleague Mark recently published an article that looked at the process involved with creating your own private CA server<\/a>. 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\u2019s review a few of them:<\/p>\n\n\n\n You can breathe a sigh of relief in knowing that your root CA distribution is limited to network devices. Private CA certificates aren\u2019t publicly trusted, so they won\u2019t be used by external users, clients, operating systems or services. Therefore, you don\u2019t have to go through all the rigmarole that public CAs do in terms of root ubiquity.<\/p>\n\n\n\n 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<\/a> to match anything you need to secure (more on that in my next point).<\/p>\n\n\n\n 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:<\/p>\n\n\n\n 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.<\/p>\n\n\n<\/span><\/span>\n\n\n There\u2019s 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.<\/p>\n\n\n\n Okay, now that we have that out of the way, let\u2019s back to the topic of how to become a certificate authority. More specifically, let\u2019s address what you need to know about how to set up a certificate authority within your organization (i.e., create a private CA).<\/p>\n\n\n\n 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 \u2014 your choice or route will likely depend on your organization\u2019s resources and the PKI knowledge and skills of your IT team.<\/p>\n\n\n\n Regardless of which method you choose, just remember to install your root certificates on all of your endpoint devices. If you don\u2019t, then they\u2019re not going to do you any good because nothing on your network will trust them.<\/p>\n\n\n\n This route is what\u2019s going to give you the most control and customizability. That\u2019s because you\u2019re deciding what your platform and capabilities will entail because you\u2019re literally building everything from the ground up.<\/p>\n\n\n\n But building a company-wide public key infrastructure isn\u2019t cheap, and it\u2019s definitely something you don\u2019t want to half-ass. You need to ensure that you have the appropriate resources \u2014 knowledgeable and skilled workers, technologies, a secure space for everything to be housed, and a budget that covers all of these things \u2014 in place to ensure it\u2019s a success and isn\u2019t something that will give you nightmares. <\/p>\n\n\n\n If you\u2019re a DIY kind of person and want to tackle this process yourself, here are some of the things you\u2019ll need to know how to do.<\/p>\n\n\n<\/span><\/span>\n\n\n 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\u2019t used for other purposes (such as running other services).<\/p>\n\n\n\n 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:<\/p>\n\n\n\n You need a root CA certificate and key to get your internal CA up and running. It\u2019s a best practice to create a root CA certificate, which you\u2019ll 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.<\/p>\n\n\n\n This next step is crucial. You need to keep your keys secure so they can\u2019t become compromised yet they\u2019re still available to the people who need access have access to them. This is where a hardware security module (HSM) can help.<\/p>\n\n\n\n Hardware security modules are tamper-resistant devices that enable secure cryptographic key storage. They keep your cryptographic keys secure so that bad guys can\u2019t 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.)<\/p>\n\n\n\n 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\u2019 IT facilities, you\u2019d see that they keep these devices under lock and key, and many require multiple privileged users to use them.<\/p>\n\n\n\n However, these devices are pricy, which means they\u2019re not ideal solutions for all organizations.<\/p>\n\n\n\n If you want to learn more about HSMs and TPMs, then stay tuned to Hashed Out. We\u2019ll have a couple of articles coming out on those particular topics within the next few weeks.<\/p>\n\n\n\n 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\u2019re a small mom-and-pop outfit with just a handful of devices to manage. But when you\u2019re a large enterprise with thousands of devices and, perhaps, spread across multiple geographic locations, this seemingly simple task becomes virtually impossible to handle. <\/p>\n\n\n\n This brings us to the next step\u2026<\/p>\n\n\n\n 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\u2019re going to create. You could<\/em> use manual tracking methods like spreadsheets, but that\u2019s a logistical nightmare that\u2019s likely going to result in headaches down the road.<\/p>\n\n\n\n The other option is to use the Microsoft CA (Active Directory Certificate Services [AD CS]) API<\/a> to manage your PKI internally. However, this requires building custom integrations to make Microsoft CA work with all of your network\u2019s 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\u2019t have in house.<\/p>\n\n\n\n This brings us to the second option for creating a certificate authority for internal resources: use a third-party PKI platform or service provider. <\/p>\n\n\n\n A managed PKI<\/a> 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.<\/p>\n\n\n\n Third-party MPKI providers offer many advantages for businesses that want their own private CAs, including:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n<\/span><\/span>\n\n\n Every business has its own unique needs, and I\u2019m not about to presume to tell you what you need. Clearly, creating a public CA isn\u2019t 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.<\/p>\n\n\n\n As you\u2019ve learned, there are clear advantages to using a private CA. And while it\u2019s nice to know that you have the option of building your own internal CA, in many cases, it\u2019s better to rely on a trusted third party to help simplify the process.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Not sure how to become a certificate authority? We\u2019ll break all of that down for you in addition to explaining the differences and uses of public and private CAs Trying…<\/p>\n","protected":false},"author":17,"featured_media":14789,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":"","tve_updated_post":"","tve_custom_css":"","tve_user_custom_css":"","tve_globals":{},"tcb2_ready":0,"tcb_editor_enabled":0,"tve_landing_page":"","_tve_header":"","_tve_footer":""},"categories":[16,10200],"tags":[164,13126],"class_list":["post-14781","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hashing-out-cyber-security","category-monthly-digest","tag-certificate-authorities","tag-how-to-become-a-certificate-authority","post-with-tags"],"views":35189,"jetpack_featured_media_url":"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/07\/how-to-become-a-certificate-authority-feature.jpg","_links":{"self":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/14781","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/users\/17"}],"replies":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/comments?post=14781"}],"version-history":[{"count":0,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/14781\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media\/14789"}],"wp:attachment":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media?parent=14781"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/categories?post=14781"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/tags?post=14781"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"how](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/06\/your-connection-is-not-private-untrusted-root-ssl-error.png\")
<\/figure>\n\n\n\n\n
Public CAs Create a Chain of Trust That External Entities Trust Automatically<\/h3>\n\n\n\n
![\"How](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/07\/chain-of-trust.jpg\")
<\/figure>\n\n\n\n\n
Private CA Certificates Have a Chain of Trust That\u2019s Limited to Your Internal Network<\/h3>\n\n\n\n
Common Use Cases: When You Need a Private vs Public CA<\/h2>\n\n\n\n
\n
\n
How to Become a Trusted Certificate Authority (Public CA)<\/h2>\n\n\n\n
\n
You Must Meet Many Criteria From Different Operating Systems & Browsers<\/h3>\n\n\n\n
Microsoft Root Certificate Program<\/h4>\n\n\n\n
Apple Root Certificate Program<\/h4>\n\n\n\n
Chromium Project Root Certificate Program<\/h4>\n\n\n\n
Mozilla\u2019s CA and Root Store Programs<\/h4>\n\n\n\n
CA\/Browser Forum Baseline Requirements<\/h4>\n\n\n\n
\n
WebTrust Principles and Criteria and Practitioner Guidance for CAs<\/h4>\n\n\n\n
\n
You Must Invest Immense Resources (Time, Money & People) to Be Considered<\/h3>\n\n\n
![\"how](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2021\/07\/how-to-become-a-certificate-authority-costs.png\")
\n
Your Public Root CA Requires Significant Distribution Efforts<\/h3>\n\n\n\n
Simply Put, the Juice Isn\u2019t Worth the Squeeze<\/h3>\n\n\n\n
Why Becoming a Private CA Is a Better Option for Most Organizations & Enterprises<\/h2>\n\n\n\n
You Only Need to Distribute Your Root CA to Devices On Your Internal Network<\/h3>\n\n\n\n
You Can Create Customize Certificate Profiles and Policies<\/h3>\n\n\n\n
You Can Issue Certificates to \u201cThings\u201d<\/h3>\n\n\n\n
![\"Internet](\"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2018\/09\/bigstock-Internet-Of-Things-Iot-And-Net-237288322-1024x683.jpg\")
<\/figure>\n\n\n\n\n
Private CA Server Control \u2014 100% Yours (If You Want That Responsibility)<\/h3>\n\n\n\n
You Control Your Certificates\u2019 Lifecycles From Start to Finish<\/h3>\n\n\n\n
How to Create Your Own Certificate Authority (Private CA)<\/h2>\n\n\n\n
Option 1: Build and Manage Your Private CA on Your Own (Internal CA)<\/h3>\n\n\n\n
Set Up the IT Infrastructure to Support Your Private CA Server, Certificate and Key<\/h4>\n\n\n\n
Establish a Certificate Policy & Practice Statement That Guides Certificate Issuance and Management<\/h4>\n\n\n\n
\n
Create Your Root CA Key and Certificate for Your Private PKI<\/h4>\n\n\n\n
Secure Your Private CA Cryptographic Keys<\/h4>\n\n\n\n
Distribute Your Root CA to All Devices On Your Network<\/h4>\n\n\n\n
Build Custom Integrations to Manage Your Private PKI<\/h4>\n\n\n\n
Option 2: Use a Third Party to Manage Your Private CA (Managed PKI, or MPKI)<\/h3>\n\n\n\n
\n
Final Thoughts on How to Become a Certificate Authority<\/h2>\n\n\n\n
Looking for More CA-Related Content?<\/h2>\n\n\n\n
\n