27
Mar
2021
Digital Certificates – Certificate Chaining
/
Read time: 6 minutes
Public Key Infrastructure (PKI) is one-way organizations that ensure authenticity of people, devices, and more. In a well-established PKI,
certificates play a significant role in authorizing and authenticating users’ identities. Since certificates are generated, revoked, and updated regularly to keep the infrastructure functional, we need to understand how the certificates are generated, how they are used to authenticate, and how certificates are linked.
A key pair is also made when a certificate is created, composed of both a private and public key, which can be used for asymmetric encryption, digital signing, and more. The private key is often secured inside an HSM to avoid data leakage, which can lead to key compromise. Each certificate contains the certificate holder’s public key, which would give the certificate the authenticity of that public key. While establishing a secure connection, the attached public key can be used for asymmetric encryption, and the user would not need to worry about any Man in the Middle (MITM) attacks.
Now, we will break it down and start from the first certificate generated in the network to understand each concept.
Root CA certificate
The Root
CA is the backbone of a PKI and is thus kept offline. The Root CA self-signs its certificate and establishes the Root of trust between identities to issue a digital certificate. The Root CA signs a certificate for the Issuing CA and other Intermediate CAs, such as Policy CAs, in the case of a three-tier architecture.
The Root certificate is similar to any other certificate you may come across, but the Root certificate generally does not contain a CDP or an AIA. Since no one can revoke a Root certificate, if the Root CA is compromised the whole PKI would need to be changed. If the Root CA is a public CA, its certificate can be added to Certificate Trusted Lists (CTLs) found in the Certificate Manager tool (certmgr.msc), and thus the root certificate will be trusted.
Intermediate CA or Issuing CA
The Root CA signs a certificate for Issuing CAs and gives them the ability to create end-entity certificates assigned to an identity of a user, device, or program. Issuing CA certificates are signed using the Root CA’s private key.
The certificate also contains Authority Info Access (AIA), which shows certificate viewers the URL of the Root certificate, which is the issuer of the Issuing CA’s certificate.
The Issuing CA’s certificate also contains the CRL Distribution Points (CDP), which can confirm whether or not the certificate has been revoked.
The Issuing CA certificate is used to generate end-entity certificates, and the certificate’s private key is used to sign those end-entity certificates.
End Entity Certificates
End Entity certificates are issued by the Issuing CA, which uses its private key to sign the certificate. End entity certificate can be a server certificate or a device certificate such as a firewall. End entity certificates can be used for security services such as authentication, data confidentiality, and data integrity.
Each certificate contains a public key that can be used as a digital signature to encrypt data, establish encrypted sessions, etc.
Certificate Chaining
A certificate chain is a hierarchy of certificates that starts from end entity certificates. It is traced back to the issuer, which finally leads up to the Root CA’s self-signed certificate.
Certificate chains are used to verify the public key’s authority and other information in a typical TLS/SSL certificate, including if the certificate belongs to the subject mentioned. To verify this, the signature of the certificate is verified with the public key contained in the issuer’s certificate, whose signature is further verified by its issuer’s public key. This is continued until we reach the Root certificate, the last certificate in the chain.
To verify certificate chaining, the following steps are taken:
The issuer of each certificate should match with the subject of the following certificate. So, the end entity’s certificate’s issuer should correspond with the subject of the Issuing CA’s certificate, and so on. This should continue until we get to the Root certificate, which would be self-signed. This Root certificate’s issuer and the subject would be the same. If we successfully verify all certificates from end-entity to Root, it confirms that the certificates are properly chained.
When a certificate is issued, the private key of that CA is used to sign the certificate, and its respective public key would be attached to the Issuing CA’s certificate. Thus, the issued certificate signature should be verified by the public key in the issuer’s certificate.
The root certificate is the trust anchor of the PKI. The root certificate should be stored in Microsoft Certificate manager, letting browsers trust certificates having the Root certificate as the last certificate in their certification path.
Thus, for a certificate to be trusted, the certificate should have a valid issuer and should trail back to a trusted root CA. Therefore, all Intermediate CAs and end-entity certificates would become trusted.
Verifying Certificates
When a browser downloads an end-entity certificate, it is also downloading the issuer’s certificate or a bundle of certificates. When the verification of the certificate starts, firstly, the certificate chain is built. If it was successful and the root certificate is verified, the certificate’s validation period is checked. If the certificates are valid and the certification chain was also successfully built, the certificate can be trusted. If any of the validations were missed, the browser would warn or stop the user from visiting the website.
Conclusion
Certificates are crucial in this connected world, where certificates can be used for authentication, encryption of communication and data, and for ensuring data privacy. Incorrectly configured PKIs can lead to bad certificates and thus should not be trusted. Browsers will also show a warning or completely block the user from visiting a website with untrusted certificates. A healthy Public Key Infrastructure should create certificates that can create certificate chains and verify signatures, thus achieving a trusted network of users, devices, and programs.
