What is the Certificate Chain of Trust?

The SSL/TLS internet security standard is based on a trust relationship model, also called “certificate chain of trust.”

x.509 digital certificates validate the identity of a website, organization, or server and provide a trusted platform for the user to connect and share information securely.

SSL/TLS internet-based Public Key Infrastructure (PKI) allows users to exchange data using public and private key pairs, obtained and exchanged by a trusted certificate authority (CA). This reputable entity is responsible for issuing, retaining, and revoking public key certificates over insecure networks.

When you visit a website via a secure connection, the site sends a digital certificate to your browser. Your internet browser compares the issuer with a list of trusted Certificate Authorities (Root CA). If a match can’t be found, the client browser checks to see whether a trusted Root CA signs the issuing CA certificate. The browser’s chaining engine continues verifying the issuer of each certificate until it finds a trusted root or upon reaching the end of the trust chain.

The chain of trust certification aims to prove that a particular certificate originates from a trusted source.

If the certificate is legitimate and links back to a Root CA in the client browser’s Truststore, the user will know that the website is securely based on interface trust indicators, as shown below.

Web browser trust indicators

However, suppose the chain of trust fails verification. In that case, a certificate can not prove its validity on its own, and the browser will warn the user of a potential security risk, as shown below.

Web browser unsecured website warning

However, private PKI certificates are not globally trusted by major operating systems, web browsers, or applications. While they can issue X.509 certificates internally, only certificates from a publicly trusted CA can prevent the browser from sending warning messages.

There are three basic types of entities that comprise a valid chain of trust: Root, Intermediate, and End-entity. Let’s take a closer look at each in this next section.

A root certificate is a self-signed certificate that follows the standards of the X.509 certificate. A multi-level hierarchical chain of trust enables web clients and applications to verify a trusted source has validated the identity of the end-entity.

If the Trust Anchor private key is compromised, all certificates signed under that private key will be compromised, and all certificates issued by that CA will be affected. This will lead to the re-issue of new certificates by the CA to every intermediate CA and end-entity in the certificate chain.

As a result, the root CA must keep a close watch over its private key and rarely sign end-entity certificates directly. Instead, the root authority will create and sign one or more intermediate CAs to issue certificates and link them back to the root CA.

At least one intermediate certificate will almost always be present in an SSL certificate chain. They provide a vital link to enable the Root CA to extend its trustworthy reputation to otherwise untrustworthy end-entities.

The issuing CA functions as middlemen between the secure root and server certificate. This allows the Root CA to remain securely stored offline, providing an extra level of security.

Trust in the root CA is always explicit. Each operating system, 3rd party web browsers, and custom applications ship with over 100 pre-installed trusted root CA certificates. In contrast, non-root certificates are implicitly trusted and are not required to be shipped with an OS, web browser, or certificate-aware application.

Server certificates provide security, scalability, and compliance with CA standards. However, certificates do not guarantee that the subject is trustworthy, reputable in his business dealings, compliant with any law, or safe to do business with.

The end-entity provides critical information to the issuing CA via a Certificate Signing Request form. The certificate is then signed and issued by a trusted CA, attesting that the information provided was correct at the issuance time. The SSL connection to a server will fail if the certificate has not been verified and signed.

Server Certificate Subscribers are not always the party to the certificate; the use of cases varies depending on the certificate environment’s requirements. The certificate issued to an organization for its employees only verifies that the CA has authenticated the requested information from one representative of that organization, not each employee.

For example, a Root CA may issue certificates that identify a specific role that the Subscriber holds instead of a particular individual (e.g., the “Chief Information Officer” is a unique individual, whereas the “IT Staff Member” is not.) This type of role-based certificate is used when non-repudiation is desired.

Root CA may also issue a group certificate when multiple subscribers share a Private Key certificate.

If several entities act in one capacity, the CA must maintain a list of Subscribers who have access to the private key and account for the period during which each Subscriber has control of the key.

Certificate Authorities may perform functions related to both Private PKI Services and Public Key Operations, including the receipt of applicable certificate requests, the issuance, revocation, and renewal of digital certificates.

You may have noticed that Intermediate CAs are functionally similar to Root CA. However, they often have fewer Key Usage functions enabled. A valid X.509 certificate from a trusted issuer is only valid for the use specified in the Certificate Policies. Certificates that comply with these chain policy rules may still be invalid for other uses with features such as Security / MIME (SMIME), Authenticode, or Secure Sockets Layer (SSL). Further processing may be required to determine whether the certificate is valid for a specific policy.

The Intermediate Certificate contains Key Use extensions that define the possible uses or purposes of the certificate.

The certificate’s purpose can be one of four key usage settings and extended key usage fields identified in the certificate:

• Encryption: Cryptographic keys for encryption and decryption will be included in a certificate for this purpose.
• Signature: The certificate for this purpose will contain cryptographic keys for signing data only.
• Signature and encryption: A certificate for this purpose shall cover all primary uses of the certificate’s cryptographic key, including data encryption, data decryption, initial logon, or digital signature.
• Signature logon and smartcard logon: The certificate for this purpose allows the initial logon of the smart card and the digital signing of the data; it can not be used for data encryption.

There will be one root CA and one or more subordinate CAs. Subordinated CAs provide redundancy and load balancing, while the root CA is usually offline. Here, even if the subordinate CA is compromised, the root CA can revoke the subordinate CA, thereby providing redundancy.

It’s also called a cross-certification model. CAs form a peer-to-peer relationship here. This model is challenging to manage as the number of CAs increases. This kind of trust relationship can happen when different company divisions have different CAs, and they need to work together.

Bridge CA overcomes the complexity of the Web of Trust model. Here, Bridge CA acts as a central coordinating point. All other CAs (known as Principals) must trust the Bridge CA only.

The Root CA Certificate is located by rebuilding the Certification Path. When a computer finds multiple trusted certification paths during the Certificate Validation process, the Certificate Chain Engine searches for the best certification path by calculating each chain’s score. The score is calculated based on the quality and quantity of information that the certificate’s path can provide. If the scores for multiple certification paths are the same, the shortest chain will be selected.

The Windows operating system allows the following four methods to retrieve certificates from certificate chains:

1. Via the local certificate shop;
2. Use a PKCS#7 container with a full or partial chain;
3. Use the extension of the Authority Information Access (AIA) extension;
4. Crypt32.dll and the website for Microsoft Update.

Let’s take a closer look at each of these methods.

CryptoAPI uses the local certificate store search to obtain the required certificate that reduces the time for building the certificate chain. However, this applies only to CA certificates that have already been installed by an application provider (for example, an OS or a browser vendor). If the local certificate store does not contain the required certificates, other certificate retrieval methods will be attempted.

The PKCS#7 certificate retrieval method is prevalent on the Internet. A PKCS#7 message can store multiple certificates and act as a certificate container. This method allows server applications to simplify the building of a certificate chain by delivering a complete or partial certificate chain certificate. Main web servers, Apache and Microsoft IIS, send all certificates by default, and no additional configuration is required to support PKCS#7.

Similar behavior can be observed when exploring the signatures of Authenticode. When signing a binary file, a certificate chain may be included in the signature, and these certificates will be used to construct a chain by validating each signature. Although this method is beneficial, it is not always available for applications. For example, when connecting to the SSTP VPN, the VPN server does not send intermediate certificates to the client.

If your computer is connected to the Internet, the Certificate Chain Engine will check the Microsoft Update website. And if it is found (as in the example above), it is downloaded and installed in the certificate store. If your computer is not connected to the Internet, CCE will extract the certificate content from the crypt32.dll library and install the certificate in the Trusted Root CAs container.