How HTTPS certificates are checked
The padlock in the address bar is the visible result of a check that happens in a fraction of a second: the browser has confirmed that the server…
Updated:
The padlock in the address bar is the visible result of a check that happens in a fraction of a second: the browser has confirmed that the server it reached is the one the address names, and that the connection between them is encrypted. Behind that padlock is a certificate, a chain of signatures leading to an authority the browser already trusts, and a set of rules about what the certificate covers and for how long. Understanding the check explains why warnings appear, what they mean and when it is safe to ignore them (almost never).
How the browser checks a certificate chain
When you open https://example.com, the server presents a certificate: a small file containing its public key, the domain names it is valid for, a validity period, and a digital signature from a certificate authority (CA). The browser then performs several checks:
- Name match. The domain you typed must appear in the certificate, either exactly or through a wildcard such as
*.example.com. A certificate forexample.comdoes not coverwww.example.comunless both are listed. - Validity period. The current date must fall between the certificate’s start and expiry. Public certificates are limited to roughly a year, and many are issued for ninety days and renewed automatically.
- Chain of trust. The certificate is signed by an intermediate CA, which is signed by a root CA. The browser or operating system ships with a list of trusted roots. If the chain leads to one of them and every signature verifies, the certificate is trusted.
- Revocation. The browser may check whether the certificate has been revoked, using OCSP responses stapled by the server or lists distributed by the browser vendor. Revocation checking is imperfect, which is one reason short lifetimes are preferred.
- Proof of possession. During the TLS handshake, the server proves it holds the private key matching the certificate’s public key. Without this step, anyone could copy a public certificate and pretend to be the site.
Only when all checks pass does the browser finish the handshake and display the page. From that point, traffic is encrypted with keys derived during the handshake, so the network operator sees which site you connected to but not what you sent or received.
What the padlock means and does not mean
The padlock says: you are talking to the server that controls this domain name, over an encrypted channel. It does not say the site is honest, safe or run by who it claims to be. Certificates are issued automatically to anyone who proves control of a domain, so a phishing site at paypa1-secure-login.com can have a perfectly valid certificate. Verifying identity remains your job: read the domain name, not the padlock.
Reading the warnings
- “Your connection is not private” / NET::ERR_CERT_DATE_INVALID. The certificate has expired, or your device’s clock is wrong. Check the clock first; a dead laptop battery frequently resets it.
- Name mismatch. You reached a server whose certificate is for a different name, often because a hosting provider’s default certificate was served, or because
wwwand non-wwwwere not both included. - Unknown authority. The chain does not end at a trusted root. This happens with self-signed certificates on internal devices, with corporate proxies that inspect traffic, and with genuine attacks. On a public site this is a strong signal to stop.
- Revoked. The certificate was cancelled, usually because its private key leaked. Do not proceed.
Clicking through a warning disables the identity check for that site. On a home router or a lab device you configured yourself, that can be acceptable. On a bank, a shop or an email provider, it never is; the right response is to close the tab and try again later or from another network.
For site owners
Free certificates from Let’s Encrypt and similar authorities have made HTTPS the default. The remaining work is operational: automate renewal so expiry never happens, include every hostname you serve, redirect HTTP to HTTPS, and enable HSTS so browsers refuse insecure connections in future. Monitor expiry dates with an external checker, because the failure mode, a site that suddenly shows a full-page warning to every visitor, is both embarrassing and avoidable. If a private key is ever exposed, revoke the certificate and issue a new one immediately.
Reading certificate warnings correctly
- Treat the padlock as proof of encryption and domain control, not of trustworthiness. Read the domain.
- Never bypass a certificate warning on a site where you enter credentials or payment details.
- If many sites suddenly show warnings, suspect your device clock, a network proxy or malware before suspecting the sites.
- Site owners should automate renewals and test both
wwwand bare-domain variants. - Click the padlock to inspect the certificate when something feels off; the issuer and names are shown in plain language.
Frequently asked questions
Why do certificates expire so quickly?
Short lifetimes limit the damage from a stolen key and force operators to keep automation working. Ninety-day certificates renewed automatically are more reliable in practice than yearly ones renewed by hand.
What is the difference between DV, OV and EV certificates?
They differ in how much the CA verified about the organisation. Browsers now display them identically, and the extra validation offers little practical benefit to visitors, so most sites use domain-validated certificates.
Can a certificate be faked?
Forging a signature is not feasible, but a CA can be tricked or compromised into issuing a certificate for a domain it should not. Certificate Transparency logs make such issuances public so they can be detected and revoked.
A valid certificate proves who controls the domain and protects the channel; judging whether to trust that domain is still up to you.
In short: Browsers check that a certificate matches the domain, is within its validity period, chains to a trusted authority, has not been revoked and is backed by the server’s private key. Passing those checks secures the connection; it does not vouch for the site behind it.