What is a Subordinate CA?
In Internet public key infrastructure (Internet PKI), public trust ultimately resides in the root CA certificates safeguarded by certification authorities such as SSL.com. These certificates are built into end users’ web browsers, operating systems, and devices, and allow users to both trust the identities of Internet servers and establish encrypted communications with them (for more detailed information, see SSL.com’s article on Browsers and Certificate Validation).
Because they are the primary technology enabling trusted and secure communication on the Internet and are difficult and expensive to establish and maintain, the private keys of publicly trusted root certificates are extremely valuable and must be protected at all costs. Therefore, it makes the most sense for CAs to issue end-entity certificates to customers from subordinate certificates (sometimes also referred to as intermediate certificates). These are signed by the root certificate, which is kept securely offline, and are used to sign end-entity certificates, such as SSL/TLS certificates for web servers. This creates a chain of trust leading back to the root CA, and the compromise of a subordinate certificate, however bad that may be, does not result in the disastrous need to revoke every certificate ever issued by the root CA. Codifying this common-sense response to the situation, the CA/Browser Forum Baseline Requirements prohibit issuing end-entity certificates directly from root CAs and essentially require that they be kept offline, mandating the use of subordinate CAs (also known as issuing CAs) in Internet PKI.
In addition to keeping the root CA safe, subordinate CAs perform administrative functions within organizations. For example, one subordinate CA may be used to sign SSL certificates and another for code signing. In the case of public Internet PKI, some of these administrative separations are mandated by the CA/Browser forum. In other cases, which we wish to examine more closely here, a root CA may issue a subordinate CA and delegate it to a separate organization, conferring the ability to sign publicly trusted certificates to that entity.
Why You Might Need One
The short answer is that a hosted subordinate CA offers you the greatest possible control over the issuance of publicly trusted end-entity certificates, at a fraction of the potential cost of establishing your own root CA and/or private PKI infrastructure.
While a PKI chain of trust may contain more than three certificates, and may be arranged in complex hierarchies, the overall principle of root, intermediate, and end-entity certificates remains consistent: entities controlling subordinate CAs signed by trusted root CAs can issue certificates that are implicitly trusted by end users’ operating systems and web browsers. Without a subordinate CA that exists as part of a chain of trust to a root CA, an organization can only issue self-signed certificates that must be manually installed by end users, who must also make their own decisions about whether to trust the certificate or not, or build a private PKI infrastructure (see below). Avoiding this usability impediment and potential bar to trust, while maintaining the ability to issue custom certificates at will according to your organization’s business goals, is one of the primary reasons why you might want your own subordinate CA as part of your organization’s PKI plan.
There are a number of other compelling reasons that an organization may wish to acquire its own subordinate CA. A few of these are:
- Branded Certificates. Enterprises such as web hosting companies may wish to offer branded public-facing SSL/TLS certificates to their customers. With a subordinate CA signed by a public root CA, these companies can issue publicly trusted certificates in their own name, at will, without having to establish their own root CA in browser and operating system root stores or investing heavily in PKI infrastructure.
- Client Authentication. Controlling a subordinate CA confers the ability to sign certificates that can be used to authenticate end-users’ devices and regulate access to systems. A manufacturer of digital thermostats or set-top boxes might wish to issue a certificate for each device, ensuring that only its devices may communicate with its servers. With its own subordinate CA, the enterprise has complete control over issuing and updating certificates as needed on the devices they manufacture, sell, and/or provide services for. Specific business needs may require or benefit from using publicly trusted rather than private PKI in this role. For example, an IoT device might include a built-in web server for which the manufacturer wishes to issue a uniquely identifiable, publicly trusted SSL/TLS certificate.
- Customization. With its own subordinate CA, and bearing in mind that public-facing certificates are subject to CA/Browser Forum Baseline Requirements, an organization is free to customize and configure its certificates and their lifecycle to meet its particular needs.
Private vs. Public PKI
When forming a PKI plan, businesses must make choices between private and public PKI. For the purposes of this article, it is most important to note that if an organization wishes to issue public-facing certificates and expect them to be implicitly trusted, the organization must have a subordinate CA signed by a publicly trusted root CA, or manage to get their own self-signed certificate trusted by the various root programs. Without a chain of trust to a root CA, end users are forced to make their own determination of trust rather than simply relying on their operating system and browser root stores. On the other hand, if public trust is not needed, a private PKI infrastructure frees an organization from needing to adhere to standards regulating public PKI. In this case, it is possible, to cite a popular solution, to use Microsoft Active Directory Certificate Services for in-house PKI. See SSL.com’s article on this topic for a more detailed explanation of public vs. private PKI.
In-House vs. SaaS
When weighing the benefits of private vs. public PKI, it is also important for an organization to consider the potential cost of staffing and hardware, and realize that they will be responsible for the security of their own private root and subordinate keys. If public trust is required, the effort necessary to establish and maintain compliance with OS and browser root programs is considerable to the point of being insurmountable for many organizations. Hosted PKI for both public and private CAs is now available from multiple root certificate authorities (including SSL.com) and can help enterprise customers avoid much of the expense and effort of in-house PKI. A hosted subordinate CA typically allows organizations to issue and manage the lifecycle of end-entity certificates via a web-based interface and/or API offered by the host. Hosted PKI, publicly trusted or not, also gives organizations the peace of mind of knowing that their host’s PKI facilities and processes undergo regular, thorough, and expensive audits, and that they will be actively maintained and updated as standards and best practices evolve.
Conclusion
If your organization needs the ability to issue publicly trusted certificates, a hosted subordinate CA is a cost-effective and convenient solution. If you feel that a subordinate CA could be a good option for you, please do not hesitate to contact us at support@stg.ssl.com for more information.
And, as always, thanks for your interest in SSL.com, where we believe a safer Internet is a better Internet.
