Preface: Components of a PKI
Public key infrastructure (PKI) is a core technology in the identity and security stack. This technology uses encryption to allow entities such as an individual or device to be uniquely identifiable and able to store or transmit information securely. All modern organizations use PKI in some form or another. The digital certificate on a website that protects customers’ privacy and data is an example of PKI in action.
Fortunately, the fundamentals haven’t changed significantly since PKI was formally introduced in the X.509 standard in 1988. In this five-part blog series, we cover a few of the most important PKI components:
- Digital Certificates
- Certificate Authorities and CA Hierarchies
- Certificate Revocation
- Active Directory Certificate Services
- Hardware Security Modules
Part 2: Certificate Authorities and CA Hierarchies
In Part 1 of our “Components of a PKI” blog series, we defined several PKI terms that are useful for understanding Certificate Authorities (CAs—also known as Certification Authorities) and CA hierarchies:
- Issuer: A generic term referring to the parent certificate that signed the issued certificate; this is typically a CA
- CA: An entity that issues certificates
- Certificate chain: Trust path created by the issuer/CA
- CA hierarchy: Design/structure of the CAs in the certificate chain
What is a Certificate Authority
In cybersecurity, a Certificate Authority (CA) plays a pivotal role in ensuring secure communication over networks. A Certificate Authority is a trusted entity responsible for issuing digital certificates that authenticate the identities of parties involved in online transactions. These digital certificatescontain cryptographic keys that validate the integrity and authenticity of data exchanged between users and servers. By rigorously verifying the identity of entities requesting certificates, a Certification Authority establishes trust in the digital realm, safeguarding sensitive information from unauthorized access and mitigating risks associated with cyber threats. Thus, the Certificate Authority serves as a cornerstone in building a secure and resilient cybersecurity infrastructure.
Public vs. Private Certificate Authorities
You’re probably already familiar with Transport Layer Security/Secure Sockets Layer (TLS/SSL) web server certificates issued by public CAs. All major operating systems and browsers automatically trust a list of well-known global CAs. When you connect to the Ravenswood Technology Group website using HTTPS, the issuer of our TLS/SSL certificate (DigiCert) is already trusted by your browser. If you click the lock icon in your browser, as Figure 1 shows, you’ll see the certificate chain for our website, similar to Figure 2.
Some organizations run their own private CAs using Microsoft Active Directory Certificate Services (AD CS) that are trusted exclusively within their organization. This can be for a variety of use cases, such as domain controllers, smart cards, S/MIME email encryption, file encryption, SCCM client certificates, network access via 802.1x EAP-TLS, etc.
Root CA
Root CAs are the highest CA in the certificate chain hierarchy. During the inception of a PKI, the root CA is characterized as an irrevocable self-signed certificate that acts as the foundation of trust for all issued certificates (e.g., subordinate CAs or end-entity certificates). Additionally, the certificate properties defined during the creation of the root CA can constrain the capabilities of issued certificates.
If the root CA is compromised, the entire PKI must be rebuilt. Reducing the attack surface of the root CA is extremely important, and it’s not uncommon for a root CA to be physically air-gapped from the network for the lifetime of the PKI. In that scenario, PKI administrators will need to power on the root CA only to publish Certificate Revocation Lists (CRLs) or build additional subordinate CAs.
Trusting a root CA in your browser or operating system automatically bypasses the default “Do you trust this certificate?” security safeguards. Rogue CAs could introduce attack vectors such as:
- Websites (man-in-the-middle or phishing attacks)
- Code execution (malicious signed executables, Microsoft Office macros, scripts)
- Identity and access (malicious networks, authentication servers, S/MIME, document signing)
Although it’s possible to issue end-entity certificates directly from the root CA, as Figure 3 shows, most PKIs will issue end-entity certificates from subordinate CAs in a two-tier CA hierarchy. If you look back to the example of our website in Figure 2, the root certificate is “DigiCert” and the issuing CA is “DigiCert SHA2 Secure Server CA.” The end-entity certificate is www.ravenswoodtechnology.com.
Subordinate, Intermediate, and Issuing CAs
Subordinate CAs exist between the root CA and the end-entity certificates to allow for superior organization and improved security. Like the root CA, certificate properties defined during the creation of the subordinate CA can constrain the capabilities of issued end-entity certificates. An organization may decide to add additional subordinate CAs for a variety of reasons, such as:
- High availability (publishing certificate templates on CAs in multiple regions)
- Ease of administration
- Administrative boundary (e.g., Philippines IT manages Singapore issuing CA)
- CA intended purpose (e.g., TLS server CA, workstation CA, etc.)
- Network design/restrictions (e.g., region-specific CAs)
The most common deployment is a two-tier CA hierarchy with an offline root CA and one or more subordinate CAs generally referred to as “issuing CAs.” The issuing CAs are always online to issue end-entity certificates.
Another variation of the two-tier CA hierarchy is implementing one or more subordinate CAs based on the intended certificate type/usage. These types of subordinate CAs are often referred to as “issuing/policy CAs” because they are characteristic of both issuing CAs and policy CAs. The term “policy CA” is specific to three-tier CA hierarchies, but common deployment scenarios for issuing/policy CAs or policy CAs include:
- Adding administrative boundaries (e.g., Mobile Device Management—MDM—client CA managed by MDM team)
- Adding name constraints (e.g., only issues certificates to *.ravenswoodtechnology.com)
- Adding application policy constraints (e.g., only issues certificates for “secure email”)
- Adding separate certificate policies (CPs) and certificate practice statements (CPSs)
As Figure 5 shows, this variation of the two-tier CA hierarchy includes two separate issuing/policy CAs for client certificates and server certificates. In this example, “Ravenswood SHA2 Client CA” may be managed by a separate team (e.g., various members of the help desk team have permissions to revoke certificates) and may be configured with application policy constraints that prohibit the issuance of valid end-entity certificates with intended purposes other than client authentication, secure email, smart card logon, and Key Distribution Center (KDC) authentication.
In the most complex scenarios, a three-tier CA hierarchy may be required. A subordinate CA is referred to as an intermediate CA if it exists between the root CA and subordinate issuing CAs, and a policy CA is an intermediate CA that introduces technical constraints (e.g., name/application policy constraints) or procedural constraints (e.g., administrative boundary or separate CP/CPS) on subordinate CAs or end-entity certificates. Depending on the requirements of the PKI, the intermediate CAs may be deployed online or offline. An additional use case of the three-tier CA hierarchy is the ability to revoke intermediate CAs at the second tier without losing all branches to the root CA.
As Figure 6 shows, the three-tier CA hierarchy has two branches from an offline root CA. The first branch is an offline “Ravenswood Internal Int CA” intermediate policy CA with two online subordinate issuing/policy CAs. The second branch is an offline “Ravenswood Partner Int CA” intermediate policy CA with two online subordinate issuing/policy CAs. In this example, the “Ravenswood Internal Int CA” and “Ravenswood Partner Int CA” intermediate policy CA branches are implemented with separate CP/CPS procedures and name constraints, and they provide administrative boundaries for delegating access to subordinate CAs and issuing end-entity certificates for internal versus partner usage.
Final Remarks
Designing and supporting a Certificate Authorities hierarchy can be a surprisingly difficult task for an organization, and the decisions made when implementing a CA hierarchy are expensive and time-consuming to change. In our experience, many organizations have internal CAs that are either under-engineered (unable to meet security/business needs) or over-engineered (unnecessarily complex or costly to support). We work with organizations to reduce their total cost of ownership by optimizing their internal PKI solution or replacing it with a third-party managed PKI solution. If you want feedback on your organization’s PKI solution, our team can help! Contact Ravenswood Technology today.
Read more in Part 3 of this blog series: Certificate Revocation.
