The main purpose of this document is to explain the PKI term ‘Chain of Trust’.


PKI (Public Key Infrastructure) is a framework built upon protocols, services and standards used to provide authentication, confidentiality, integrity, non-reproduction and access control to digital data.
The term ‘Chain of Trust’ is used to describe the trust relationship between identities when using Subordinate (intermediate) CA`s. The key benefit to this is to allow the delegation of certificates by Subordinate CA`s.


To provide a ‘Chain of Trust’ a number of components are needed. They are:

CA (Certificate Authority) – A Certificate Authority is an authority that issues public key certificates and provides identification to the bearer.
Subordinate CA (Certificate Authority) – A Subordinate CA is a certificate authority (CA) that is at a level beneath the root CA.
Certificates – A digital certificate provides authenticity to a users or clients identity. A digital certificate contains a number of details relating to the client such as address, DN, email address etc. Each digital certificate is issued (and signed) by a CA (Certificate Authority) and is only valid for a specific period of time.
Key Pairs – A key pair consists of a public and private key. Any data that is encrypted with the public key can be decrypted with the private key and vice-versa. The public key can be provided to anyone who requests it and is typically formed as part of the public certificate. The private key (as the name suggests) is keep private and not shared.
Digital Signatures – A digital signature is generated by the hashing of a digital certificate. The hash is then encrypted using the CA`s private key. This encrypted md5 string is then appended to the public certificate as a digital signature.
As only the CA`s public key can decrypt the digital signature, authenticity is  provided to the users public certificate.
CSR – Though this is not directly considered a component within a ‘Chain of Trust’ its explanation is still beneficial due to its place within the certificate signing process. A Certificate Signing Request (CSR) is a base-64 encoded (PEM based) string which is generated using the users public key along with a number of attributes provided by the user such as DN, email, address etc. The CSR is then sent to the CA which it then uses to create a public certificate. The public certificate is then signed and sent back to the user. The benefit in using a CSR is that the private key never leaves the client.


The over arching ‘Chain of Trust’ hierarchy lies within the trust relationships between each identity.
This can be seen within the diagram below.


During the signing process the Root CA digitally signs the intermediate certificate using its private key. This provide authenticity that the intermediate certificate is trusted by the Root CA.
Next the Sub CA (intermediate CA) signs the identity Certificate using its private key. This provides authenticity that the identity certificate is trusted by the Intermediate CA.


Using a typical scenario of a user connecting to an SSL web-page, we will walk through the steps required to provide a ‘Chain of Trust’.

  1. The client wants to view an SSL website. For this he will use a web browser. By default each browser is preloaded with a number Root CA (public) certificates.
  2. The client connects to the SSL website.
  3. The website responds with the Identity and Intermediate certificates.
  4. The client confirms authenticity of the Intermediate certificate by decrypting the digital signature using the Root CA`s public key.
  5. Next the client confirms the authenticity of the identity certificate by decrypting the digital signature using the intermediates public key.
  6. The client then clarifies that the URL that is being requested by matching the DN (Distinguished Name) within the Identity Certificate. If this does not match the browser displays a warning.
  7. Traffic is then encrypted/decrypted by a) the ‘client’ using the public key b) the ‘server’ using the private key.