What is Certificate chain? And how to validate Certificate chain
PKI commonly known as the public key infrastructure Is a framework for facilitating Digital certificates and public-key encryption. This Framework ensures secure communication between two parties over the internet. There are so many policies constraints and standards to build trust between two parties.
Multiple levels of trust. If two parties are trusting each other It calls direct trust. Also if two parties are trusted for each other because of the third party, Then it calls a third-party trust. I in PKI that Trust comes from the 3rd party and that third-party calls the certificate authority or commonly known as CA’s.
Who are CA’s (certificate authority)?
CA’s are the global organizations that provide digital certificates to their clients, there could be external CA’s (Such a GlobalSign, VeriSign) or internal CA’a specific to its organization.
Then the simple question comes. why we need these certificate authorities..? Well as he explained earlier if you need to build trust with a third party then we need a trusted third party. In this case that trusted third party is this certificate authority.
This could be explained with a simple example. Let’s assume someone needs to purchase an item from the online shopping site. in order to make the payment, That user uses an online payment gateway such as PayPal. In this case, both the online shopping site as well as the user is trusting that PayPal will handle the payment for that item.
Now let’s see how this is applicable for securing services provided through the internet.
Certificate Chains in internet
In technical terms there are two main models are there 2 issuing certificates.
- Hierarchical trust model
- Distributed trust model
Hierarchical trust model
In the hierarchical model, There is only one self-signed certificate, which signs all other digital certificates With its private key. the limitation of this model is that if the private key is compromised, Then all the rest of the issued certificates become useless. Therefore the hierarchical model is not commonly used in modern applications.
Distributed trust model
To overcome that limitation, What is introduced in the distributed trust model is an intermediate layer. This intermediate layer has multiple certificate authorities, Where the root certificate authority delegated it’s the responsibility of signing digital certificates. In this case, compromising a private key of one certificate authority will not affect the rest intermediate certificate authorities as well as the digital certificates signed by them. This calls a chain of trust, And this is the model more commonly used on the internet.
Technical Explanation
When you go to facebook.com you will see a green lock icon in the address bar.
What that means is you have made a secure connection between your computer and facebook.com over the internet. And how that trust works. If you explore further and see the certificate it will look like below.
And you can see that the certificate is issued to facebook.com, And it was issued by DigiCert Inc (With the common name of DigiCert SHA2 High Assurance Server CA).
And if we check the certificate chain, The next intermediate certificate (DigiCert SHA2 High Assurance Server CA), Was issued by the DigiCert High Assurance EV Root CA according to the common name.
And when we check the Root certificate, You can see both subject and the issuer is the DigiCert High Assurance EV Root CA. Because these top-level CA certificates are Self Signed Certificates. Usually, these high-level Root certificates and also the intermediate trusted certificates are by default available in the browser and the OS trust stores.
Then these certificates available in trust-store, Will use it’s public key to verify the root certificate, Once it verifies it will trust the intermediate certificate and eventually the server certificate.
In this case, How my browser trust facebook.com as follows.
- Root certificate is validated against the trusted list of certificates available in OS trust store.
- Intermediate certificate is validated since it is singed by DigiCert High Assurance EV Root CA and it was verified.
- Finally the site certificate was validated since it was signed by DigiCert SHA2 High Assurance Server CA which is the verified intermediate CA in the previous step.
This is a brief description about the certificate chains and how it is used in the internet. Not let’s see if we need to verify and validate the certificate chain and some common commands related to that.
Get metadata from certificate using OpenSSL
OpenSSL is an open source SSL utility tool which is available for all common platforms. And it has capabilities such as generate private keys, create CSRs, install your SSL/TLS certificate, and identify certificate information..etc.
Some common OpenSSL commands
- Display full information of certificate.
openssl x509 -text -noout -in <Cert File>- Get the subject of the certificate
openssl x509 -noout -subject -in <Cert File>- Get the issuer of the certificate
openssl x509 -noout -issuer -in <Cert File>- Convert certificates to different formats
openssl x509 -inform <input_format> -outform <output_format> -in <Cert File> -out <Output file>- Verify certificate
openssl verify <> -CAfile <ca_cert> -untrusted <intermediate cert> <cert file>Please note that you can provide multiple intermediate certs with -untrusted parameter
How to verify certificate chain
Let’s assume we have 3 certificates as below (I have used facebook’s cert chain for this example).
- server.pem is the server certificate file.
- im.pem is the intermediate certificate file.
- root.pem is the CA certificate file.
According to this, If we get the server.pem files issuer, It should be the im.pem files subject. In this case.
user@Users-MBP cert % openssl x509 -noout -issuer -in server.pemissuer= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CAuser@Users-MBP cert % openssl x509 -noout -subject -in im.pemsubject= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
According to this output, It seems like the issuer and subject matches appropriately. We can use openssl verify command to verify this.
user@Users-MBP cert % openssl verify -untrusted im.pem server.pemserver.pem: OK# If wrong cert use user@Users-MBP cert % openssl verify -untrusted root.pem server.pemserver.pem: C = US, ST = California, L = Menlo Park, O = "Facebook, Inc.", CN = *.facebook.comerror 20 at 0 depth lookup:unable to get local issuer certificate
Like that, We can verify adjacent certificate with openssl commands. Same can apply to verify the CA and intermediate certificates.
user@Users-MBP cert % openssl verify -untrusted root.pem im.pemim.pem: OK
And also, You can certify the whole cert chain as fallows.
user@Users-MBP cert % openssl verify -CAfile root.pem -untrusted im.pem server.pemserver.pem: OK
In a successful cert chain validation, issuers and subjects match according to the above diagram.
Creating a one single certificate chain from 3 separate certificates
During a cert rotation, If CA singed certificate is used in most cases 3 or more separate certificate files come in the bundle. For some load balancers and some of the servers, It needs to be imported as a single cert bundle file. In that case, we need to contact the certs into one file and create a bundle. To do that following procedure could be used.
- If the certs are not in PEM format, Then convert them into PEM files.
openssl x509 -inform der -outform pem -in root.cer -out root.pem- Merge files in the following order.
Server certificate →Intermediate certs → Root certificate
user@Users-MBP cert % cat server.pem im.pem root.pem > bundle.pemOnce you did that, We can use the following command to check whether the cert chain was created according to the correct order.
user@Users-MBP cert % openssl crl2pkcs7 -nocrl -certfile bundle.pem | openssl pkcs7 -print_certs -nooutsubject=/C=US/ST=California/L=Menlo Park/O=Facebook, Inc./CN=*.facebook.comissuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CAsubject=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CAissuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CAsubject=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CAissuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
Hope this will help you to understand the certificate chains as well as some useful commands to work with the cert chain.
Happy Coding
