Home » Wiki » What is an Intermediate Certificate?

What is an Intermediate Certificate?

by | SSL Certificate

What is an Intermediate Certificate

Understanding Intermediate Certificates

An intermediate certificate, also known as intermediate CA certificate, is used in public key infrastructure (PKI) to form a chain of trust between the root certificate authority (CA) and end-entity certificates issued to servers, devices, or individuals.

Intermediate certificates play an important role in the public key infrastructure by linking end-entity certificates back to the root CA certificate. They allow the root CA to issue certificates without having to be directly involved in validating and issuing end-entity certificates.

How Intermediate Certificates Work

Here is how intermediate certificates work in a PKI hierarchy:

  • The root CA issues an intermediate certificate to a subordinate CA or an intermediate certificate authority.
  • The intermediate CA will then use this certificate to issue end-entity certificates to servers or other entities that require certificates.
  • The intermediate certificate is digitally signed by the private key of the root CA. This establishes a link between the intermediate CA back to the trusted root.
  • When a client or relying party receives an end-entity certificate, it can validate the certificate by checking the issuer signature against the intermediate CA certificate.
  • The client can then validate the intermediate certificate by checking its signature against the known trusted root CA certificate. This establishes a chain of trust from end-entity to intermediate and root.
  • The intermediate certificate avoids the need for the root CA to be involved in issuing and validating every single end-entity certificate. The root CA delegates this responsibility to intermediate CAs.
  • The intermediate CA restricts the scope of authority of the end-entity certificates compared to being directly signed by the highly trusted root CA.

Purposes of Intermediate Certificates

Intermediate certificates serve several important purposes:

Establish a Chain of Trust

Intermediates allow a chain of trust to be established from end-entity certificates back to the root CA, enabling relying parties to validate the trustworthiness of certificates.

Limit Scope of Authority

Intermediates limit the scope of authority of end-entity certificates compared to being directly signed by the root CA. This provides greater risk management.

Administrative Delegation

Intermediates enable administrative delegation of CA duties to subordinate CAs without involving the root CA directly. This improves efficiency and scalability.

Technical Segmentation

Intermediates allow technical segmentation of CA functions across different systems, keys and policies as needed for organizational reasons.

Lifespan Management

Intermediates can be reissued periodically with a new key to limit the lifespan of certificates, while keeping the same root CA in place longer term.

Key Compromise

If an intermediate key is compromised, the intermediate can be revoked without needing to revoke the root CA or all end-entity certificates.

Browser & Platform Support

Some web browsers and platforms require a chain of intermediate certificates connecting back to a root for certificate validation.

Types of Intermediate Certificates

There are a few common types and naming conventions used with intermediate certificates:

Public Intermediates

A public intermediate certificate is intended to issue end-entity certificates to external parties such as customers or partners. These are commonly named publicly as “Public Intermediate CA #1”, “Public Intermediate CA #2”, etc.

Private Intermediates

A private intermediate certificate is meant for issuing certificates for the organization’s internal uses and entities. These are often named as “Private Intermediate CA #1”, “Private Intermediate CA #2”, etc.

Policy OID Intermediates

Some organizations classify intermediates based on certificate policies using unique OID identifiers in the certificate. For example, “Policy 1 Intermediate CA” or “Smartcard Logon Intermediate CA”.

Geography Intermediates

Global organizations sometimes segment intermediates based on geographic regions such as “APAC Intermediate CA” or “EMEA Intermediate CA”.

Intermediate Certificate Hierarchies

PKI deployments can establish complex multi-level hierarchies using intermediates. Here are some common intermediate CA hierarchy models:

Single Intermediate

In a simple model, the root CA issues a single intermediate CA certificate. This intermediate is then used to issue end-entity certificates. It establishes a direct 2-level hierarchy.

Chained Intermediates

The root CA can issue an intermediate CA, which then issues another intermediate certificate below it. This chains two or more levels of intermediates that inherit trust from the root CA.

Branched Intermediates

A root CA can issue multiple intermediate CAs, each designated for a specific region, department or function. This branches the hierarchy while still anchoring trust at the root CA.

Cross-certified Intermediates

Intermediates from different organizations can cross-certify each other enabling trust between separate PKIs. This establishes intersecting chains of trust.

How to Create and Sign Intermediate CAs

Several steps are required to create and sign an intermediate certificate authority:

  • Generate a key pair for the intermediate CA – a public and private key. Store the private key securely.
  • Create a certificate signing request (CSR) for the intermediate CA public key.
  • Sign the intermediate CA CSR with the root CA using the root’s private key. This establishes the issuer chain of trust.
  • Set an appropriate validity period for the intermediate CA certificate’s issued and expiry dates. A shorter lifespan is better for risk management.
  • Include conventions in the intermediate CA name to designate its purpose per your PKI’s policies e.g. Public Issuing CA #1.
  • Add Certificate Policies, Key Usage and Extended Key Usage extensions required by your PKI policies.
  • Publish the intermediate CA certificate into your PKI repositories and distribution channels.
  • Revoke expired or compromised intermediate CAs promptly to maintain trust chain integrity.

Now the intermediate CA can be used to begin issuing certificates for end-entity uses based on your PKI policies.

Installing Intermediate Certificates

For relying parties to validate the certificates issued by an intermediate CA, the intermediate certificates must be installed and trusted on those systems:

Web Browsers

Import the intermediate CA certificate into the browser’s trust store either manually or through automated policy. Browsers like Chrome, Firefox, IE and Edge have trusted root stores.

Mobile Devices

Install the intermediate CA certificate on mobile operating systems like iOS and Android so certificates can validate on those platforms. This may involve MDM or manual methods.

Servers

For servers and devices, install the intermediate CA certificate into their trust stores. This includes Windows certificate stores, Java trust stores or Linux distributions.

Applications

Some client applications maintain their own trust stores. You may need to import intermediate certificates into products like Adobe Acrobat, Office 365 Apps or OpenSSL distributions.

Smart Cards

If using smart cards for certificate-based authentication, the intermediate certificates need to be added to the trust anchor module on the cards.

Following best practices for each platform or device will ensure proper intermediate CA certificate trust distribution.

Revoking Intermediate Certificates

It’s critical to revoke intermediate certificates promptly when:

  • The intermediate CA private key is compromised or suspected to be compromised.
  • The intermediate CA reaches its expiry date and is not renewed.
  • Your PKI policies or business practices change requiring intermediate CAs to be deactivated.
  • An audit reveals improper use of an intermediate CA that must be deactivated.

Revocation tells relying parties that an intermediate CA can no longer be trusted to verify certificates. You should publish revoked intermediates in your Certificate Revocation List (CRL) and/or Online Certificate Status Protocol (OCSP) responder.

Browsers and applications will check these revocation sources when validating certificates and stop trusting revoked intermediates for certificate verification.

It’s also important to track down any end-entity certificates issued by a revoked intermediate CA and replace them with new certificates issued by your valid intermediates to avoid outages.

Best Practices for Intermediate Certificates

Here are some best practices to follow when establishing and maintaining intermediate certificates:

  • Minimize use of intermediate CAs when possible and issue end-entity certificates directly from the root CA for highest security.
  • Only create intermediates when the organizational benefits outweigh the additional complexities.
  • Keep the intermediate CA private keys securely stored and highly restricted.
  • Set shorter validity periods on intermediates e.g. 2 years or less. Requires more maintenance but reduces risk significantly.
  • Revoke and replace compromised intermediate CAs immediately to maintain trust. Have spare intermediates available for rapid rollover if needed.
  • Have documented policies and procedures for creating, auditing, renewing and revoking intermediate CAs.
  • Automate certificate lifecycle management processes for intermediates where possible for efficiency and reliability.
  • Distribute intermediate CA certificates to all relevant systems and devices that need to validate end-entity certificates.

Following these best practices will lead to robust protection for your PKI infrastructure using intermediate CAs.

Conclusion on Intermediate Certificate

Intermediate certificates serve a critical function in public key infrastructures by establishing chains of trust between end-entity certificates and root certificate authorities. They enable the secure scaling of certificate hierarchies while limiting the scope of authority of end certificates. When leveraged properly following best practices, intermediates provide significant security, administrative and technical benefits. However, it is important to restrict, secure and actively manage intermediate CAs to mitigate risks of compromise. Overall, intermediates help bridge the gap between trusted roots and domain validators to facilitate secure internet communications through Public Key Infrastructure (PKI) trust chains.

FAQs

What is an intermediate certificate?

An intermediate certificate is issued by a root certificate authority to a subordinate CA to establish a chain of trust between the root and end-entity certificates issued to servers, devices or individuals.

Why are intermediate certificates used instead of having the root CA directly issue end-entity certificates?

Intermediates provide segmentation of duties, scoping of authority, and lifespan management benefits compared to the root CA issuing everything directly.

How many levels of intermediate CAs can you have?

There can be multiple layers of chained, branched or cross-certified intermediates, however it is recommended to keep the hierarchy as flat as possible for manageability.

Where should intermediate certificate private keys be stored?

Private keys for intermediate CAs should be securely stored in cryptographic hardware like HSMs or smart cards with restricted access controls.

How often should you rotate intermediate certificate keys?

It is a best practice to issue intermediate certificates with shorter validity of 2 years or less and rotate the keys frequently for improved security.

Can an intermediate certificate be used to issue other intermediate certificates?

Yes, an intermediate CA can generally issue additional subordinate intermediate CAs, expanding the tree of trust.

How do you revoke a compromised intermediate certificate?

Publish the revoked intermediate on your CA’s Certificate Revocation List (CRL) and/or via Online Certificate Status Protocol (OCSP) responder.

Priya Mervana

Priya Mervana

Verified Web Security Experts

Priya Mervana is working at SSLInsights.com as a web security expert with over 10 years of experience writing about encryption, SSL certificates, and online privacy. She aims to make complex security topics easily understandable for everyday internet users.