One-way organizations such as Public Key Infrastructure (PKI) assure the validity of individuals, devices, and more. Certificates are crucial for approving and validating user identities in a well-established PKI. We must comprehend how certificates are issued, used to authenticate, and connected since certificates must be routinely generated, revoked, and updated to maintain the infrastructure operational.
When a certificate is made, a key pair is also made, consisting of a private and public key that may be used for asymmetric encryption, digital signature, and other purposes. To prevent data leakage, which might result in key compromise, the private key is frequently safeguarded inside an HSM Each certificate contains the public key of the certificate holder, giving the certificate the legitimacy of that public key. The connected public key may be used for asymmetric encryption during the establishment of a secure connection, and the user won’t have to worry about Man in the Middle (MITM) attacks.
What is Certificate chain order: Chain of trust
The SSL certificate chains are issued in a predefined sequence. The certificate Chain order is:
Root CA certificate
Since the Root CA is the foundation of a PKI, it is kept offline. In order to issue a digital certificate, the Root CA self-signs its certificate and creates a root of trust between identities. In the event of a three-tier architecture, the Root CA signs a certificate for the Issuing CA and additional Intermediate CAs, such as Policy CAs.
The Root certificate is comparable to any other certificate you could see, although it typically lacks a CDP or an AIA. Since a root certificate cannot be revoked, if the root CA were to be hacked, the entire PKI would need to be updated. The root certificate will be trusted if the Root CA is a public CA and its certificate is added to the Certificate Trusted Lists (CTLs) in the Certificate Manager tool (certmgr.msc).
Intermediate CA or Issuing CA
The power to produce end-entity certificates tied to the identity of a user, device, or application is granted to issuing CAs by the Root CA. The Root CA’s private key is used to sign certificates issued by other CAs.
Additionally, the certificate includes Authority Info Access (AIA), which displays the URL of the Root certificate—the certificate issued by the Issuing CA—to readers of the certificate.
The CRL Distribution Points (CDP), which can determine whether or not the certificate has been revoked, are also included in the certificate issued by the issuing CA.
The private key of the issuing CA certificate is used to sign the end-entity certificates that are created using the certificate’s public key.
End Entity Certificates
The Issuing CA uses its private key to sign End Entity certificates before they are issued. A server certificate or a certificate for a piece of equipment, such a firewall, might be the end entity certificate. Data confidentiality, data integrity, and other security services can be provided via end entity certificates.
Certificate chain validation
Each certificate has a public key that may be used to encrypt data, create encrypted sessions, etc. and act as a digital signature.
In a normal TLS/SSL certificate, the public key’s authority and other details, such as the certificate’s affiliation with the topic indicated, are verified via certificate chains. This may be confirmed by comparing the certificate’s signature to its issuer’s public key, which is used to confirm the certificate’s signature with the issuer’s public key. Up to the Root certificate, the final certificate in the chain, this is continued.
Each certificate’s issuer should correspond to the certificate’s topic. As a result, the issuer of the certificate for the end entity should match the subject of the certificate for the issuing CA, and so on. Up to the Root certificate, which would be self-signed, this should continue. The topic and the issuer of this Root certificate would be the same. It is proof that the certificates are correctly chained if we are able to successfully check every certificate from the end-entity to the root.
When a certificate is issued, the issuing CA’s private key is used to sign the certificate, and the issuing CA’s public key is added to the certificate it issues. Therefore, the public key in the issuer’s certificate should be used to verify the signature of the issued certificate.
The PKI’s trust anchor is the root certificate. In order for browsers to trust certificates with the Root certificate as the final certificate in their certification route, the root certificate should be kept in Microsoft Certificate Manager.
As a result, a certificate must have a legitimate issuer and track back to a reputable root CA in order to be trusted. As a result, end-entity certificates and intermediate CA certificates alike would be trusted.
Verifying Certificates
A browser also downloads the issuer’s certificate or a collection of certificates when it downloads an end-entity certificate. The certificate chain is initially constructed when the certificate verification process begins. The validity time of the certificate is examined whether it was successful and the root certificate was validated. The certificate can be trusted if the certificates are legitimate and the certification chain was properly constructed. The user would be warned or prevented from browsing the website if any of the validations were failed.
Certificate Chains on the Internet
Technically speaking, there are two primary approaches for issuing certificates:
- Hierarchical trust model
- Distributed trust model
Hierarchical trust model
In the hierarchical architecture, there is only one self-signed certificate that uses its private key to sign all other digital certificates. The drawback of this strategy is that all other issued certificates become useless if the private key is compromised. As a result, current programmes do not frequently employ the hierarchical paradigm.
Distributed trust model
The distributed trust architecture introduces an intermediary layer in order to get around that restriction. The root certificate authority outsourced the task of signing digital certificates to many certificate authorities in this intermediate layer. In this scenario, the compromise of one certificate authority’s private key will not have an impact on the other intermediate certificate authorities or the digital certificates they have signed. This is referred to as a chain of trust, and this is the concept that is most frequently applied online.
Conclusion
In today’s interconnected world, where certificates may be used for authentication, data and communication encryption, and data privacy protection, certificates are essential. PKIs that are incorrectly setup should not be trusted since they might produce subpar certificates. Additionally, users who try to access a website with an untrusted certificate may get a warning or have their browsers totally reject them. In order to achieve a trusted network of people, devices, and programmes, a healthy public key infrastructure should be able to produce certificates that can establish certificate chains and validate signatures.
