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.
Watch certificate checking happen in curl's verbose output. -I asks for headers only, so we can focus on the connection.
Step 1/3: 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.
Quiz
Your browser shows "your connection is not private, certificate expired" for a shopping site. What is technically true at that moment?
Problem
What do we call the trusted organization that verifies a domain owner and signs their TLS certificate? (Two words, or its two-letter abbreviation.)