Trust stores and chains of trust—an introduction
HTTPS leverages public-key encryption to safeguard browser communications from being intercepted or altered during transit across the Internet. Visiting browsers are supplied with a public key by servers, which is then utilized to set up an encrypted connection for all following data transfers. Nevertheless, the receipt of a functional public key does not assure that the corresponding server is genuinely owned by the legitimate entity, individual, company, or organization. Man-in-the-middle attackers have the capacity to tamper with networks to distribute their own keys, thereby jeopardizing any communication.
To thwart this form of tampering, browsers authenticate HTTPS servers using certificates. These digital certificates are machine identities that link a public key to a specific subject. This linkage is affirmed by a trusted Certification Authority (CA), which confirms the identity of the certificate holders, through both automated and manual verification against approved databases.
Certificates are digital files and they follow a file format to store information (e.g. signatures, keys, issuers, etc.). Publicly-trusted PKIs, which are trusted by the browsers, must conform to RFC 5280, which requires the use of the X.509 v3 format. X.509 v3 allows certificates to include additional data, such as usage constraints or policy information, as extensions. Each of these extensions is either critical or non-critical, with browsers being required to process and validate all critical ones.
Image 1: X.509 v3 Certificate Format
Certificate Authorities (CAs) use a private key to cryptographically sign all certificates they issue. This signature serves as an unchangeable verification that a particular CA issued a certificate and that there were no modifications after the signing. The CA asserts ownership of this signing key by possessing a root certificate, also known as a trust anchor, that corresponds to the public key. The creation, management, and usage of a root by CAs are strictly regulated and audited, in compliance with the Baseline Requirements set by the CA/B Forum.
All certificates beneath the root certificate place their trust in it and use the root certificate's public key to sign other certificates. The trustworthiness of the root certificate forms the basis for verifying SSL/TLS connections by numerous software applications, including browsers. Given the high value of these root certificates and the potential risks associated with their compromise, they are seldom used to issue end-entity certificates. Instead, intermediate certificates are typically used. These intermediate certificates are then used to issue certificates for their clients. An intermediate certificate forms a "Chain of Trust" between an end-entity certificate and a root certificate.
All certificates below the root certificate put trust into the root certificate and the public key of the root certificate is used to sign other certificates. Many software applications inherit the reliability of this root certificate like the browsers verifies the SSL/TLS connections on the base of root certificate trustworthiness. Because of the value of these root certificates, and the risks that come with having one compromised, they are rarely used to issue end-entity certificates. Instead, we use intermediate certificates. These intermediates can then be used to issue their customers’ certificates. An intermediate certificate plays a “Chain of Trust” between an end-entity certificate and a root certificate.
This is how it works. The root CA signs the intermediate root with its private key, which makes it trusted. Then the CA uses the intermediate certificate’s private key to sign and issue end-user SSL certificates. This process can be repeated several times, where an intermediate root signs another intermediate and finally to sign an end-entity certificate. These links, from root to intermediate to end entity, are the certificate chain or chain of trust.
Having a closer look at the chain of trust, and keeping in mind the X.509 v3 certificate format, the candidate certification path must "name chain" between the recognized trust anchor and the target certificate (i.e., the end-entity certificate). Working from the trust anchor to the target certificate, this means that the Subject Name in one certificate must be the Issuer Name in the next certificate in the path, and so on. Image 2 below helps to illustrate this concept. In this example, the path begins with a self-signed certificate that contains the public key of the trust anchor. The path ends with the end-entity certificate. All other certificates within the path are referred to as intermediate CA certificates. Note that every certificate in the chain except for the last one is a CA certificate.
Image 2: Chain of Trust or Certification Path
Browsers are shipped with a built-in list of trusted roots, called a trust store. A trust store is a collection of root certificates that are trusted by default and are maintained by the companies that make operating systems and web browsers, such as Apple, Microsoft, Mozilla, and Google. Each vendor has its own standards and requirements for root certificates but they all require an issuing CA to undergo one or more audits proving their trustworthiness, validity and conformance with the CA/B Forum Baseline Requirements, before their root certificate is included. To verify a certificate, a browser will obtain a sequence of certificates, each one having signed the next certificate in the sequence, connecting the signing CA’s root to the server’s certificate.
Browser certificate validation process
Once a potential certification path has been established, browsers authenticate it by utilizing the data embedded within the certificates. A path is deemed valid if browsers can cryptographically confirm that, originating from a trust anchor, the private key corresponding to each certificate was employed to generate the subsequent one in the path, leading all the way down to the end-entity certificate. RFC 5280 provides a conventional algorithm that browsers adhere to when validating a certification path of X.509 certificates.
Image 3: Certificate Validity Verification
Essentially, browsers verify all certificates in the path, starting from the trust anchor, and authenticate each certificate's fundamental data and vital extensions. Once the process reaches the final certificate in the path without any discrepancies, the path is deemed valid. If inconsistencies arise, the path is labeled as invalid.
Regardless of any extensions, browsers are obligated to always validate basic certificate data like the signature or the issuer. The sequence of validations that browsers execute are as follows:
1. The browser confirms the certificate’s integrity
The certificate's signature can be authenticated using standard public-key cryptography. If the signature is found to be invalid, it implies that the certificate has been altered post-issuance and is consequently rejected.
2. The browser confirms the certificate’s validity
A certificate’s validity period is the time span during which the signing CA guarantees to maintain its status information. Browsers dismiss any certificates with a validity duration that ends before or begins after the date and time of the validation check.
3. The browser checks the certificate’s revocation status
When a certificate is issued, it is anticipated to be in use for its entire validity duration. However, certain circumstances may cause a certificate to become invalid before its natural expiration. Such situations might include a suspected compromise of the certificate’s private key. In such instances, a CA must revoke the corresponding certificate. This is accomplished through the use of revocation lists.
There are two methods for informing users of certificate revocation. One is through Certificate Revocation Lists (CRL). CAs periodically issue a signed, time-stamped list of revoked certificates called a certificate revocation list (CRL). CRLs are distributed in publicly available repositories, and browsers can acquire and consult the CA’s latest CRL when validating a certificate. One flaw of this method is that the time granularity of revocation is limited to the CRL issue period. A browser will be notified of revocation only after all currently issued CRLs are scheduled to be updated. Depending on the signing CA’s policy, this might take an hour, day, or even up to a week.
An alternate method is the Online Certificate Status Protocol (OCSP), outlined in the standard document RFC6960. This protocol allows a browser to request the revocation status of a specific certificate from an online OCSP server. When properly set up, OCSP is far more immediate and circumvents the issue of CRL update latency mentioned earlier. Moreover, OCSP Stapling enhances both performance and speed.
4. The browser verifies the issuer
Typically, X.509 certificates are associated with two characteristics: the issuer, or the entity that owns the signing key, and the subject, referring to the owner of the public key that the certificate verifies (refer to Image 1 above). Browsers verify that the issuer field of a certificate matches the subject field of the preceding certificate in the certificate path.
5. Constraints processing
Following the above steps, browsers check the certificate constraints, if these have been defined by the CA. Every certificate in the path can impose additional constraints that all subsequent certificates must obey. These constraints might be a name, policy, and key usage.
(This post has been updated. It was originally published on October 7, 2019.)