HTTPS uses public-key encryption to protect browser communications from being read or modified in transit over the Internet. Servers provide visiting browsers with a public key that is used to establish an encrypted connection for all subsequent data exchanges. However, receiving a working public key does not guarantee that the associated server is indeed owned by the legitimate subject, person, company or organization. Man-in-the-middle attackers can manipulate networks to serve their own keys, thereby compromising any communication.
Browsers prevent this type of manipulation by authenticating HTTPS servers using certificates, which are digital documents that bind a public key to an individual subject. The binding is asserted by having a trusted Certification Authority (CA) verify the identity of the certificate owners, via automated and manual checks against qualified 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
CAs use a private key to cryptographically sign all issued certificates. Such signatures can irrevocably prove that a certificate was issued by a specific CA and that it was not modified after it was signed. CAs establish ownership of their signing key by holding a root certificate, called also a trust anchor, for the corresponding public key. CAs have to observe tightly controlled and audited procedures to create, manage and utilize a root in accordance with the Baseline Requirements established by the CA/B Forum.
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.
After a candidate certification path is constructed, browsers validate it using information contained in the certificates. A path is valid if browsers can cryptographically prove that, starting from a trust anchor, each certificate’s corresponding private key was used to issue the next one in the path, all the way down to the end-entity certificate. RFC 5280 describes a standard algorithm that browsers follow to validate a certification path of X.509 certificates.
Image 3: Certificate Validity Verification
In a nutshell, browsers iterate through all certificates in the path starting with the trust anchor, validating each certificate’s basic information and critical extensions. If the procedure concludes with the last certificate in the path without errors, then the path is accepted as valid. If errors are produced, the path is marked as invalid.
Regardless of any extensions, browsers must always verify basic certificate information such as the signature or the issuer. The sequence of checks that browsers perform are the following:
1. The browser verifies the certificate’s integrity
The signature on the certificate can be verified using normal public-key cryptography. If the signature is invalid, then the certificate is considered to be modified after its issuance and is therefore rejected.
2. The browser verifies the certificate’s validity
A certificate’s validity period is the time interval during which the signing CA warrants that it will maintain information about its status. Browsers reject any certificates with a validity period ending before or starting 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 expected to be in use for its entire validity period. Various circumstances may cause a certificate to become invalid before it naturally expires. Such circumstances might include a suspected compromise of their private key. In cases like this, a CA needs to revoke the corresponding certificate. This is achieved with 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.
The second alternative method is the Online Certificate Status Protocol (OCSP), which is described in standard document RFC6960. OCSP lets a browser request a specific certificate’s revocation status from an online OCSP server. When properly configured, OCSP is much more immediate and avoids the CRL update-latency issue mentioned above. In addition, OCSP Stapling improves performance and speed.
4. The browser verifies the issuer
X.509 certificates are normally associated with two properties: the issuer, which is the entity owning the signing key and the subject, which refers to the owner of the public key that the certificate authenticates (see Image 1 above). Browsers check that a certificate’s issuer field is the same as the subject field of the previous 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.