Introduction
HTTPS (via SSL/TLS) 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, just receiving a working public key alone does not guarantee that it (and by extension the server) is indeed owned by the correct remote subject (i.e., person, company, or organization). Man-in-the-middle attackers can manipulate networks to serve their own keys, thereby compromising any communication.
Browsers prevent this 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 certificate authority (CA) such as SSL.com verify the identity of prospective certificate owners, via automated and manual checks against qualified databases.
This trust relationship means that web user security is not absolute; rather, it requires users to trust browsers and CAs to protect their security. Therefore, it is in every user’s interest to have a basic understanding of how certificate validation works.
Note that the certificate validation process (described in detail in the standard document RFC 5280) is quite convoluted. In this article we will try to walk you along one path (a browser validating a host’s SSL/TLS certificate) and navigate past complex details that are inconsequential to most users.
Note: As of August 2024, RFC 9618, an Internet Engineering Task Force (IETF) document, has updated the algorithm for validating policy constraints in X.509 digital certificates from RFC 5280.
Certificates and the X.509 format
Certificates are digital files in every respect, which means that they need to follow a file format to store information (e.g., signatures, keys, issuers, etc.). While private PKI configurations can implement any format for their certificates, publicly trusted PKIs (i.e., those 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, with each extension being either critical or non-critical. If a client encounters an unrecognized non-critical extension, it may ignore it. If an extension is critical and unrecognized or cannot be processed, the certificate must be rejected.
Certification Paths and Path Processing
CAs use a private key to cryptographically sign all issued certificates. Such signatures can cryptographically 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 self-issued certificate (called the root) for the corresponding public key. CAs have to observe tightly controlled and audited procedures to create, manage, and utilize a root, and to minimize exposure, they will normally use a root to issue intermediate certificates. These intermediates can then be used to issue their customers’ certificates. A root CA certificate is self-signed, and the private key is protected under stringent procedures. Issuance typically occurs through intermediaries, not directly from the roots.
Browsers are shipped with a built-in list of trusted roots. (These are roots from CAs who have passed the browser’s stringent criteria for inclusion.) 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.
This sequence of certificates is called a certification path. The path’s root is called a trust anchor and the server’s certificate is called the leaf or end entity certificate.
Path Construction
Often, web browsers and software clients in general may build to multiple candidate trust anchors (e.g., due to cross-signs) and frequently fetch missing intermediates via AIA to complete a chain. Even though a path may contain certificates that “chain” together properly to a known anchor, the path itself may be rejected due to restrictions on path length, domain name, certificate usage, or policy.
Constructing and evaluating all possible paths is an expensive process performed for every new certificate a browser encounters. Browsers have implemented various optimizations to minimize the number of rejected candidate paths, but delving into such details is well beyond the scope of this article.
Path Validation
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 certificate directly signed by 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 leaf certificate.
Baseline Requirements require that Subject and Issuer names across all possible paths be byte-for-byte identical, which simplifies reliable path building.
Certification Path Validation Algorithm
As previously noted, as of August 2024, RFC 9618, an Internet Engineering Task Force (IETF) document, has updated the algorithm for validating policy constraints in X.509 digital certificates from RFC 5280. Basically, browsers iterate through all certificates in the path starting with the trust anchor (i.e. the root certificate), 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.
Basic certificate processing
Regardless of any extensions, browsers must always verify basic certificate information such as the signature or the issuer. The following sections show the sequence of checks that browsers perform.
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. Of course, various circumstances may cause a certificate to become invalid before it naturally expires.
Such circumstances might include a subject changing their name or a suspected compromise of their private key. In cases like this, a CA needs to revoke the corresponding certificate, and users also place their trust in a CAs to notify browsers of their certificates’ revocation status.
Certificate Revocation Lists (CRL)
Certificate Revocation Lists (CRLs) have become the industry standard for certificate revocation checking as of 2024. CAs periodically issue signed, time-stamped lists of revoked certificates that browsers can download and cache locally.
While CRLs were previously considered less efficient than real-time checking methods, the industry has recognized significant advantages that make them the preferred approach:
- Enhanced Privacy: CRLs protect user privacy by eliminating the need to query external servers about specific certificates, which could reveal browsing patterns
- Operational Efficiency: CAs can manage revocation more efficiently without maintaining high-availability real-time response services
- Reduced Infrastructure Costs: Eliminating the need for 24/7 OCSP responders significantly reduces operational overhead
- Better Caching: Modern browsers can efficiently cache and update CRLs, minimizing the latency concerns that previously favored real-time methods
As of March 2024, the CA/Browser Forum requires all publicly trusted CAs to provide CRLs while making other revocation methods optional. Some major certificate authorities have discontinued alternative revocation services in favor of CRL-only approaches.
Online Certificate Status Protocol (OCSP)
The Online Certificate Status Protocol (OCSP), described in RFC 6960, was designed to provide real-time certificate revocation checking by allowing browsers to query OCSP servers (responders) about specific certificates. While OCSP was widely adopted in the 2010s as an improvement over periodic CRL downloads, the industry has largely moved away from this approach.
- OCSP is now optional for publicly trusted CAs (effective as of March 2024). The importance of OCSP is declining; for example, Let’s Encrypt removed OCSP URLs in May 2025 and shut down responders in August 2025.
- Some browsers have disabled OCSP checking or implement it in ways that provide minimal security benefits
OCSP Stapling: A variant called OCSP Stapling remains useful in some scenarios, where servers include OCSP responses directly in the TLS handshake, avoiding separate client queries to OCSP responders. However, this requires specific server configuration. Stapling is supported by most servers/CDNs, but its utility is waning as large CAs withdraw OCSP.
How this actually works today in browsers: Since March 15, 2024, the CA/B Forum requires publicly trusted CAs to publish CRLs, while OCSP is optional. Modern browsers generally don’t query OCSP or download CRLs per site. Instead, they use aggregated mechanisms built from CA-published CRLs: Chrome’s CRLSets and Firefox’s CRLite deliver fast, privacy-preserving revocation data to clients. As a result, OCSP’s role on the public Web is diminishing; for example, Let’s Encrypt removed OCSP URLs in May 2025 and shut down OCSP responders in August 2025.
4. The browser verifies the issuer
Certificates are normally associated with two entities:
- 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.
Clients verify that each certificate in the path is signed by the previous certificate’s public key and that Issuer/Subject names match exactly along the path. For added security, most PKI implementations also verify that the issuer’s key is the same as the key that signed the current certificate. (Note that this is not true for the trust anchor, since roots are self-issued – i.e., they have the same issuer and subject.)
Constraints processing
The X.509 v3 format allows a CA to define constraints or restrictions on how each certificate is validated and used as critical extensions. Every certificate in the path can impose additional constraints that all subsequent certificates must obey.
Certificate constraints rarely affect the average Internet user, though they are quite common in enterprise SSL solutions. Functional constraints can serve several operational purposes, but their most significant use is to mitigate known security concerns.
5. The browser checks name constraints
A privately owned (but publicly trusted) intermediate CA with the appropriate name constraints can provide an organization with fine-grained control over certificate management and issuance. Certificates can be limited to a specific domain or domain tree (i.e., including subdomains) for a company or organization’s domain name. Name constraints are often used for intermediate CA certificates purchased from a publicly trusted CA to prevent the intermediate CA from issuing perfectly valid certificates for third-party domains (e.g. google.com).
6. The browser checks policy constraints
A certificate policy is a legal document published by a CA, officially detailing the procedures they follow to issue and manage their certificates. CAs might issue a certificate under one or more policies, and links to these are included in each certificate issued so that relying parties can evaluate these policies before deciding to trust that certificate.
For legal and operational reasons, certificates can impose restrictions on which policies they can be subject to. If a certificate is found to contain critical policy constraints, browsers must validate them before proceeding. (However, critical policy constraints are rarely encountered in the real world and so will be disregarded for the rest of this article.)
7. The browser checks basic constraints (a.k.a. path length)
The X.509 v3 format allows issuers to define the maximum path length a certificate can support. This provides control over how far each certificate can be placed in a certification path. This is actually important – browsers used to disregard the certification path length until a researcher demonstrated, in a 2009 presentation, how he used his website’s leaf certificate to forge a valid certificate for a large e-commerce website.
8. The browser verifies key usage
The “key usage” extension states the purpose of the key contained in the certificate. Examples of such purposes include encipherment, signatures, certificate signing and so on. Browsers reject certificates violating their key usage constraints, such as encountering a server certificate with a key meant only for CRL signing.
9. The browser continues to process all remaining critical extensions
After processing the extensions mentioned above, browsers proceed to validate all remaining extensions that the current certificate designates as critical, before moving on to the next. If a browser reaches a path’s leaf certificate without error, then the path is accepted as valid. If any errors are produced the path is marked as invalid and a secure connection is not established.
Modern Certificate Management: Shorter Lifespans and Automation
The SSL/TLS industry has undergone several changes in recent years, fundamentally altering how certificates are issued and managed. Understanding these changes is crucial for PKI managers, IT professionals, and/or anyone else working with digital certificates.
Shortened Certificate Validity Periods
In April 2025, the CA/Browser Forum approved a landmark decision (Ballot SC-081v3) to dramatically reduce certificate validity periods in phases:
- Current (through March 2026): Maximum 398 days (approximately 13 months)
- March 15, 2026: Maximum 200 days
- March 15, 2027: Maximum 100 days
- March 15, 2029: Maximum 47 days
Domain Control Validation (DCV) Changes
Alongside certificate lifespans, the reuse period for domain validation information is also shrinking:
- March 2026: 200 days maximum reuse
- March 2027: 100 days maximum reuse
- March 2029: 10 days maximum reuse
This means organizations will need to validate domain ownership much more frequently, making automation essential for practical certificate management.
Why These Changes Matter
Security Benefits:
- Shorter certificate lifespans reduce the window of exposure when keys are compromised
- More frequent validation ensures domain ownership remains current
- Faster deployment of security improvements across the web
Operational Impact:
- Manual certificate management becomes practically impossible
- Organizations must implement automated certificate lifecycle management
- More frequent domain validation procedures required
Automation Requirements
These changes make certificate automation not just beneficial but essential. Organizations should strongly consider:
- Implement ACME (Automatic Certificate Management Environment) or similar protocols
- Deploy certificate lifecycle management solutions
- Prepare infrastructure for frequent renewals and validations
- Prepare for the transition to shorter certificate lifespans
Certificate Transparency Integration
Modern browsers increasingly require or validate Certificate Transparency (CT) logs, which provide public, auditable records of all issued certificates. This helps detect:
- Mis-issued certificates
- Unauthorized certificate issuance
- CA compliance issues
Conclusion
The digital landscape remains a complex system of interconnected components, and browser security continues to be an active area of development that includes:
- Shorter Certificate Lifespans: The industry is moving toward 47-day certificate validity periods by 2029, making automation essential for practical certificate management
- Revocation Method Changes: The shift away from OCSP back to CRLs reflects the industry’s prioritization of user privacy and operational efficiency
- Stricter CA Oversight: Browsers have become more aggressive about enforcing compliance and removing trust from underperforming certificate authorities
These changes represent a fundamental shift toward more automated, privacy-conscious, and security-focused certificate management. Organizations should begin preparing now for shorter certificate lifespans and automated renewal processes.
Trust continues to play a major role in keeping users safe online. We encourage you to stay informed about these evolving standards and to review your certificate authority’s policies and compliance record. As these changes demonstrate, the certificate ecosystem actively adapts to enhance security and privacy protection.
For the most current information about certificate management best practices and SSL.com’s approach to these industry changes, please visit our certificate comparison page.
Thanks for choosing SSL.com, where we believe a safer Internet is a better Internet.
