Chain Certificates

Bruce Morton

What are chain certificates? Chain certificates are referred to by many names — CA certificates, subordinate CA certificates or intermediate certificates.  Confused yet? Let’s break it down.

It all starts with something called a root certificate. The root certificate is generated by a certification authority (CA) and is embedded into software applications. You will find root certificates in Microsoft Windows, Mozilla Firefox, Mac OS X, Adobe Reader, etc. The purpose of the root certificate is to establish a digital chain of trust. The root is the trust anchor.

The presumption is that the application developer has pre-screened the CA, ensured it meets a minimum level of trust and has accepted the CA’s root certificate for use. Many application developers, including Adobe, Apple, Mozilla, Microsoft, Opera and Oracle, have root certificate programs. Others rely on the roots provided by the underlying operating system or developer toolkit.

One of the main functions of the root is to issue chain certificates to issuing CAs — the first link in the chain of trust. Your Web browser will inherently trust all certificates that have been signed by any root that has been embedded in the browser itself or in an operating system on which it relies.

Why do you need an issuing CA? The purpose of the issuing CA is to isolate certificate policy from the root. Issuing CAs can be used to issue many different certificate types: SSL, EV SSL, Code Signing, Secure Email, Adobe CDS, etc. These certificate types are subjected to different requirements and risks, and as such have different certificate policies. The certificates may have different assurance levels such as high, medium and low. Issuing CAs may also be controlled by an organization other than that which controls the root.

The last link of trust is that between the end entity certificate and the issuing CA. In the case of an SSL certificate, the end entity certificate represents the linkage between a website owner and the website domain name. The SSL certificate is installed on the Web server along with the chain certificate. When a user browses to the website protected by the SSL certificate, the browser initiates the verification of the certificate and follows the chain of trust back to the embedded root.

In some cases, the CA may have chosen to issue end entity certificates directly from the root CA. This is an outdated practice; issuing directly from the root increases risk and limits how certificate policy can be managed and enforced. Issuing directly from the root can also impact performance as the browser may have to verify a large certificate revocation list (CRL) during its chain validating process. Major public CAs are discontinuing or limiting this practice.

When you receive an Entrust certificate, we provide any required chain certificate complete with installation instructions.

Bruce Morton
Bruce Morton
Director, Certificate Technology & Standards

Bruce Morton has worked in the public key infrastructure and digital certificate industry for more than 15 years and has focused on SSL and other publicly trusted certificates since 2005. He has been an active member of the CA/Browser Forum that released guidelines for extended validation (EV) certificates and Baseline Requirements for SSL certificates. Bruce oversees the governance and compliance of Entrust’s publicly trusted PKI.


  1. m_farouk September 2, 2016 Reply

    this mean intermediate certificate is coming from sub CA

    • Bruce Morton Author
      Bruce Morton September 2, 2016 Reply

      No. The subCA can be called the subordinate CA or the intermediate CA. As such, the subCA has a subordinate certificate or an intermediate certificate. Think of the validation path as the SSL/TLS certificate is signed by the subCA and the subCA certificate is signed by the root CA. To complicate matters, there could be more than one subCA, which would mean that yes a subCA has issued an intermediate certificate. In this case, the path would be SSL/TLS certificate signed by subCA2 which is signed by subCA1 which is signed by the root.

  2. Vincent January 5, 2017 Reply

    Hi Bruce, thanks for the article, it’s very instructive. However, I’m not sure by which mechanism the chain is validated on client-side. Does that mean the endpoint has to know the full chain in its certificate store, or only the root is required? Let’s say I have an WPA2-Enterprise WIFI access point that presents a certificate emitted by L1K, chained under G2. Would I need to deploy L1K to all my Windows endpoints in the intermediate store, or should they somehow only require trusting the G2 root? Thanks!

Add to the Conversation