A Technical Overview of TLS Certificate Validation and Common Failure Points

The padlock icon represents the output of a fairly involved chain of cryptographic checks happening in milliseconds, and most of the times that chain fails in the real world, it fails for one of a small, predictable set of reasons.

Behind every padlock is a chain of trust, and a chain only holds as long as every individual link does.

In this post

1. What validation actually checks, step by step
2. The chain of trust concept, explained precisely
3. Expired certificates, the most common failure
4. Hostname mismatch, and why it exists as a separate check
5. Incomplete chains: the misconfiguration that only sometimes shows up
6. Certificate pinning and its trade-offs
7. Why validation failures should rarely be dismissed

TLS certificate validation is the process a browser or client performs to confirm that the server it has connected to is who it claims to be, before treating that connection as trustworthy. Understanding the actual steps in this process makes the common failure messages, expired, invalid, name mismatch, considerably less mysterious, and makes clear why dismissing them casually is rarely a good idea.

What validation actually checks, step by step

1. The client checks that the certificate's validity period covers the current date, rejecting anything expired or not yet valid
2. The client verifies the certificate's digital signature, confirming it was actually issued by the certificate authority it claims to be issued by, and that the certificate has not been tampered with since issuance
3. The client walks the certificate chain upward, checking each intermediate certificate's signature against the one above it, until it reaches a root certificate the client already trusts, typically one bundled with the operating system or browser
4. The client confirms the certificate's listed domain name, or one of its listed alternative names, matches the actual domain being connected to
5. The client checks the certificate has not been revoked, through either a certificate revocation list or the Online Certificate Status Protocol, depending on what the certificate authority supports and what the client checks

Only if every one of these checks passes does the client proceed to treat the connection as validated, and only at that point does a browser display the padlock icon without a warning.

The chain of trust concept, explained precisely

No individual website certificate is trusted directly. Instead, it is signed by an intermediate certificate authority, which is itself signed by a root certificate authority, and that root is one of a relatively small set pre-installed as trusted in your operating system or browser. This creates a chain: your site's certificate is trusted because it was signed by an intermediate you trust, which is trusted because it was signed by a root you trust. The entire system's security rests on that small set of root certificate authorities maintaining rigorous standards for who they issue certificates to and how carefully they verify domain ownership before doing so, which is why certificate authority governance and audit standards, documented by organizations like the CA/Browser Forum, matter far more to the overall system's integrity than most casual discussions of "the padlock" ever acknowledge.

Expired certificates, the most common failure

Certificates are deliberately issued with a limited validity period, generally no longer than about thirteen months under current industry baseline requirements, specifically to limit the damage window if a certificate's private key is ever compromised, and to force regular re-verification of domain ownership. Most expired certificate incidents in practice trace back to a failed or missed renewal, particularly common on manually managed certificates rather than ones using automated renewal through a system like Let's Encrypt's ACME protocol, which is exactly why automated renewal has become the strongly preferred default approach for anyone managing their own certificates today.

Hostname mismatch, and why it exists as a separate check

A certificate is issued for a specific domain name, or a specific set of names through the Subject Alternative Name extension, and a client will reject the connection if the domain being visited does not match any name on the certificate, even if every other part of the chain validates correctly. This check exists specifically to prevent a scenario where a legitimately signed, currently valid certificate for one domain gets presented on a completely different domain, which without this check would let an attacker reuse any valid certificate on any server they controlled, regardless of who it was actually issued to.

Incomplete chains: the misconfiguration that only sometimes shows up

A server needs to present not just its own certificate but the full chain of intermediate certificates up to a trusted root, and a common misconfiguration involves a server presenting an incomplete chain, missing one or more intermediates. This frequently produces an inconsistent, confusing symptom: some clients validate the connection successfully because they already have the missing intermediate cached from a previous, unrelated connection, while other clients, without that cached intermediate, fail validation entirely on the exact same server. This inconsistency is precisely why testing a certificate configuration with a dedicated tool that checks the full chain explicitly, rather than relying on whether your own browser happens to load the site without a warning, matters for anyone responsible for a server's certificate setup.

Certificate pinning and its trade-offs

Certificate pinning is a stricter model, primarily used in native mobile apps rather than general web browsing, where an application is hardcoded to only trust one specific certificate or public key for a given service, rather than accepting any certificate that validates through the normal chain of trust process. This closes off a specific risk, a compromised or coerced certificate authority issuing a fraudulent but technically valid certificate for a domain, since the pinned app would reject even a properly chain-validated certificate that does not match its hardcoded expectation. The trade-off is operational fragility, a pinned app breaks entirely if the pinned certificate needs to be rotated without a corresponding app update shipped in advance, which is part of why pinning has become less common in its strictest form as the broader certificate ecosystem has matured.

Why casually clicking through a certificate warning is a real risk, not just an inconvenience: a certificate warning means one of the specific checks above failed, and a browser has no way to distinguish between an innocent misconfiguration, an expired certificate the site owner simply forgot to renew, and an active interception attempt presenting a fraudulent certificate. Treating every warning as automatically harmless trains exactly the habit that makes the genuinely malicious case succeed.

Why validation failures should rarely be dismissed

From an end user's perspective, a certificate warning should be treated as a stop signal rather than a formality to click past, particularly on any site handling sensitive information. From a site owner's perspective, testing your own certificate configuration periodically with a dedicated checker, rather than only trusting that your own regular browser loads the site without complaint, catches the kind of intermittent chain issues covered above before they affect a meaningful share of your actual visitors using different clients than the one you personally tested with.

The padlock icon compresses a genuinely careful, multi-step cryptographic verification process into a single, simple visual signal, and that compression is exactly why understanding what sits underneath it changes how seriously a warning deserves to be taken, and how confidently a site owner can actually claim their configuration is correct rather than merely appearing correct in one specific browser.