A root certificate authority, often referred to as the foundation of trust in your PKI system, is pivotal for authenticating a certificate chain. For this chain to be trusted, the root certificate must be embedded into the operating system’s trusted root store.
Given its role as the foundational trust element for your entire certificate chain, the root CA’s security is paramount. If malicious entities gain access to your root CA, they essentially have a master key to your digital realm. Hence, securing the root certificate authority acts as a bulwark against potential intruders. Consequently, root CAs are traditionally stored offline in concealed, fortified locations, only to be accessed and activated by the PKI team for tasks like issuing a new CA or signing a Certificate Revocation List (CRL).
This is a great question! The short (and only) answer – yes, you need a root CA. Organizations are recommended to use a Two-Tier CA Hierarchy (more detail below), which requires a root CA. Whether you want to run it or give it to Keytos, it honestly makes no difference – root CAs are paramount to your security posture. Before deciding how to implement it and how many CAs to chain to your root CA, though, it is important that you consider the scale of your organization, the technical infrastructure you have in place, and the CA hierarchy that your organization chooses.
Large enterprises can use one root CA to chain up multiple CAs and have one trusted root, such as having an Intune CA, a Smartcard CA, and an SSL CA, and only having to push one root to all their devices. On the other hand, SMBs – while they might only have one issuing CA – are still recommended to have a root CA as a root of trust that is kept offline and kept secure.
Maintaining your own root CA requires money, manpower and expertise. It is vital to take into consideration the resources that your organization may or may not have to manage the many responsibilities associated with a root CA, like CRL updates, HSM management, and a secure storage location for the CA.
Additionally, if you anticipate your organization growing or expanding its digital services in the near future, having a root certificate authority could streamline the process of adding and authenticating new services. Organizations aiming for a more agile approach to adapting to future technological shifts might also benefit from their own root CA.
CA hierarchy is, put simply, the number of tiers (levels) per each CA, and choosing the number of tiers in a CA hierarchy is vital to effective PKI planning. There are three options to choose from: Single/One-Tier Hierarchy, Two-Tier Hierarchy, and Three-Tier Hierarchy. Root CAs play an important role in all of these tiers, with each tier having different roles for the root CA and, hence, different ways for the root CA to interact with the issuing CA. Check out this blog outlining the difference between a root CA and an issuing CA to learn more. We recommend organizations use a Two-Tier PKI Hierarchy, but feel free to check out our blog defining what is a CA hierarchy and which CA hierarchy you should use for more information on that front.
When creating EZCA, the Azure based PKI, we were cognizant of the varied needs of our clientele. Some clients might have pre-existing offline root CAs under the care of their PKI experts, while others might lack a root CA and wish to avoid the complexities and costs linked with its upkeep, such as managing CRLs, Hardware Security Modules (HSM), and ensuring the root CA’s secure storage. With this in mind, EZCA offers flexibility by accommodating both user-provided root CAs and managed root CAs.
