Encryption without identity is worthless
Suppose an attacker on your network intercepts your connection and answers as if it were yourbank.com. You would then set up a perfectly encrypted channel... with the attacker. Encryption only helps if you also verify who is on the other end.
That is what a certificate does. During the TLS handshake, the server presents a digital document that says: "I am yourbank.com, here is my public key". The critical part is the signature at the bottom:
- The certificate is signed by a Certificate Authority (CA), a company like Let's Encrypt or DigiCert whose job is verifying domain ownership before signing.
- Your browser and OS ship with a built-in list of CAs they trust (the root store).
- Signatures often chain: a trusted root CA signs an intermediate CA, which signs the server's certificate. The browser walks this chain of trust from the server's cert up to a root it recognizes.
The browser also checks that the certificate's domain matches the URL and that it has not expired (certs are valid for a limited time, typically about 90 days for Let's Encrypt). Any failure produces the full-page browser warning you have probably seen. The warning means: encryption is possible, but the identity proof failed, so it could be anyone over there.
A recorded session
Watch certificate checking happen in curl's verbose output. -I asks for headers only, so we can focus on the connection.
Each step below shows the command and the output it printed.
Step 1. A healthy HTTPS connection. curl reports the TLS version, then the certificate's subject (who it claims to be), its validity dates, its issuer (the CA), and the verdict.
$ curl -vI https://example.com 2>&1 | grep -E 'SSL|subject|issuer|expire|OK' * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * subject: CN=example.com * expire date: Nov 20 23:59:59 2026 GMT * issuer: C=US; O=DigiCert Inc; CN=DigiCert TLS RSA SHA256 2020 CA1 * SSL certificate verify ok. HTTP/1.1 200 OK
Step 2. Now a site whose certificate has expired. The handshake is aborted, no HTTP happens at all. Note the error names the exact problem.
$ curl -I https://expired.badssl.com
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.se/docs/sslcerts.htmlStep 3. And a certificate that does not match the domain (issued for a different host). Same idea: identity check failed, connection refused before any request is sent.
$ curl -I https://wrong.host.badssl.com curl: (60) SSL: no alternative certificate subject name matches target hostname 'wrong.host.badssl.com'
What an expiry warning actually means
The server presented a certificate whose validity period ended, so its identity can no longer be vouched for.
An expired certificate does not stop the math. The connection could still be encrypted perfectly well, and the keys are no weaker than they were the day before.
What is lost is the identity guarantee. The CA only vouched for the domain up to the expiry date, and past it the browser has no current statement from anyone that this server is who it claims to be.
Expiry dates exist to bound the damage from a stolen private key. A certificate that never expired would be usable by a thief forever, so short lifetimes force regular reissuing and let revocation actually take effect.
Worth knowing that a badly wrong local clock causes this warning on every site at once, because the dates are checked against your machine's clock. A warning everywhere points at the clock rather than at the sites.
The organization that signs certificates
It is a certificate authority, usually written CA.
CAs verify that whoever requests a certificate actually controls the domain, then sign the certificate. Let's Encrypt and DigiCert are two examples, and your browser ships with a list of the trusted root ones.
Browsers trust that set of roots, and through the chain of trust, anything those roots have signed either directly or by way of an intermediate.
The whole system rests on that root store being small and carefully curated. A CA that signs a certificate for a domain its requester does not own breaks the guarantee for every user, which is why CAs get removed from root stores when they misbehave.
That is also the practical reason certificates are cheap or free now. Verifying domain control can be automated, so the expensive part became the trust rather than the paperwork.