How HTTPS Certificate Validation Actually Works

The question behind every secure connection

When you type https://example.com/ and press enter, the browser needs to answer one question before it sends anything: is this really example.com, and is somebody else watching?

The encryption half of that question is straightforward. The authentication half is more interesting than most explanations of HTTPS suggest, because it is a chain of trust going backwards from a document on a server to a certificate that was pre-installed on your device years ago.

What a certificate actually contains

An X.509 certificate is a signed statement about a public key. It binds a key to a set of facts:

• Subject and Subject Alternative Names. The hostnames the certificate is valid for.
• Issuer. The entity that signed it, which is a pointer to another certificate rather than a name you need to trust.
• Validity window. The date range in which it is valid.
• Public key. The key itself, used to prove the server holds the matching private key.
• Signature. The issuer’s signature over all of the above, which is what makes the contents unforgeable.

Only two of those fields do the security work. The rest is metadata.

Building the chain

Root certificates are the anchor. They are self-signed — signed with their own key — and that is fine, because they are not trusted because of their signature. They are trusted because copies are already installed in your operating system’s trust store and in whatever root program your browser uses. There are roughly 150 of them for a typical device, covering the major certificate authorities.

Everything else inherits trust from those roots. A website operator buys an intermediate certificate, usually without knowing they did so: the authority issues them an intermediate and a leaf certificate together, and the authority’s own certificate is signed by a root. The server sends the leaf and the intermediate to the browser during the handshake. The browser already holds the root.

So verification is a chain-walking operation: start at the leaf, check that whoever signed it is either a root I trust or another certificate whose signature checks out, and keep walking until I reach a root.

browser's trust store
        │
        └── Root CA (self-signed, pre-installed, trusted by definition)
              │  signs
              ▼
          Intermediate CA      ◄── sent by the server
              │  signs
              ▼
          Leaf certificate     ◄── sent by the server; contains the site's public key

If the walk terminates at anything other than a root in the trust store, the connection fails. This is why a missing intermediate certificate causes a warning: the server is sending a leaf whose issuer the browser has never heard of, and the walk dead-ends.

The three checks that actually happen

Having a valid-looking chain is not sufficient. The browser performs three distinct verifications, and all three must pass.

1. Signature verification

The browser checks that each signature in the chain was produced by the private key corresponding to the issuer’s public key. This is what stops anyone from generating their own certificate claiming to be issued by a real authority.

Modern TLS requires signature algorithms the browser understands. TLS 1.3 removed support for MD5 and SHA-1, which had known collision weaknesses — SHA-1 could produce two files with the same digest, which is precisely the property a signature must not have.

2. Hostname matching

The browser compares the hostname in the address bar against the names in the certificate’s Subject Alternative Name field.

This is the check most people assume is the whole of HTTPS, and it is the part that actually determines who you are talking to. A certificate valid for example.com will not be accepted for www.example.com unless that name is listed too — because the connection goes to a different virtual host, potentially on entirely different hardware.

This is also why a certificate cannot protect a site from DNS manipulation. If an attacker can convince your resolver that bank.com points at their server, and they hold a valid certificate for bank.com, every check above passes perfectly. The encryption is genuine; it is just genuinely encrypted to the wrong party.

3. Revocation checking

A certificate can be valid and correctly signed and still be compromised. Revocation handles that case. Two mechanisms exist and both are imperfect.

Certificate Revocation List (CRL). The authority publishes a signed file listing revoked certificate serial numbers. The browser downloads it and checks membership. CRLs grow without bound and can become hundreds of kilobytes, so browsers have mostly stopped fetching them.

OCSP. The browser asks a responder, per certificate, whether that specific certificate is still good. This is faster but leaks browsing behaviour to the responder, which is why many browsers now use OCSP stapling: the server fetches the signed status at startup and attaches it to the handshake, so no third party sees the request and the check costs the browser nothing.

Neither mechanism is reliable in practice, because both depend on a third party being online and fast. If a certificate authority’s revocation service is down — and one was during the 2013 Comodo incident — browsers are advised to fail open rather than break the internet. Modern browsers have largely moved on: TLS 1.3 clients may skip revocation checks entirely and instead rely on short certificate lifetimes, so a compromised key is only useful for a bounded window.

What the padlock does not tell you

This is the practical part, and it is where most confusion lives.

A valid certificate means the connection is encrypted and the peer holds the key for the hostname you requested. It does not mean the site is legitimate, safe, or honest. Phishing operations obtain certificates routinely — often for free, in minutes, through automated issuance. The padlock appears on a fraudulent bank clone just as readily as on your bank.

It also says nothing about what happens after the data arrives. A site can have perfect HTTPS and harvest everything you type. The protection is against someone in the network path between you and the server, not against the server itself.

What 0-RTT changes

TLS 1.3 added 0-RTT data — application data sent before the handshake completes. It saves a round trip, which matters for latency-sensitive traffic.

It is also replayable by design. An attacker who records a 0-RTT flight can resend it later, and the server cannot tell the difference from a legitimate retransmission. So 0-RTT is safe for idempotent requests — a GET, typically — and unsafe for anything that changes state, where a replayed request could mean a duplicate payment. This is a protocol-level trap for application developers rather than something an end user can manage, and it is one more reason the security of an HTTPS connection is only one part of the security of an application.

What to check when a warning appears

If a trusted site shows a warning, in descending order of likelihood:

1. Missing intermediate certificate. The server sent a leaf but not the chain above it. Real, common, and the server operator’s bug rather than an attack.
2. Hostname mismatch. The certificate predates a rename or a subdomain was added without renewing it.
3. Expired certificate. Automations that renew certificates fail more often than anyone expects, particularly when a domain changes hands.
4. System clock wrong. Validation is time-dependent, and a machine with a badly set clock will reject valid certificates.
5. A real interception proxy. Common on corporate networks, less common elsewhere. Worth knowing about, but the least likely explanation on a home connection.

The first three are all server-side problems with the same practical answer: the operator needs to fix their certificate deployment. There is nothing a reader can do about them, which is why a warning on a site you rely on is worth reporting rather than clicking through.