9.5 Website Trust Signals and Certificate Basics
What a Certificate Actually Proves
An X.509v3 certificate is a signed statement, not proof of identity. It binds a public key to names, carries validity dates and extensions -- Key Usage, Extended Key Usage for server authentication, Basic Constraints to forbid being a CA -- and ends with the issuing CA's signature over those fields. The handshake then demands proof of possession: the server signs transcript data with the matching private key. The certificate proves only that a CA vouched, at issuance time, that whoever holds this key controls these names.
Chain Building and Its Failure Modes
Path building walks leaf to intermediate to a root in the local trust store, checking each signature, validity windows, and name matching against the Subject Alternative Name -- Common Name is ignored, and a wildcard matches one label only, so *.example.com covers a.example.com but not a.b.example.com. Revocation rides stapled OCSP responses plus short lifetimes in practice. Hard failures are mundane: a missing intermediate the server failed to send, an expired leaf, a www-versus-apex mismatch, and -- the sneaky one -- an expired intermediate breaking sites whose own leaf is perfectly valid. Managed fleets with an inspection root also see unfamiliar-issuer warnings.
The Validation Ladder: DV, OV, EV
Classes differ only in what the CA checked before signing. Domain Validation proves control of the name through a DNS TXT record, a well-known HTTP path token, or mail to an administrative contact -- automatable in minutes, exactly what ACME clients do. Organization Validation additionally verifies the legal business against an approved data source under CA/Browser Forum rules and populates subject fields. Extended Validation adds stricter identity evidence and a documented process. Cryptographically all three are identical: same key types, same TLS, same padlock -- browsers removed the extended-validation visual distinction precisely because the padlock had stopped being a trust signal.
Signals That Still Mean Something
Since roughly 2018, HTTPS is table stakes: phishers get free ACME certificates in seconds, and a valid certificate on a fraudulent host is normal. Read the registrable domain, not the string -- lookalikes hide behind hyphens, path segments, or a userinfo prefix. Stronger evidence lives in the certificate viewer: issuer, the full SAN list (broad SANs hosting hundreds of brands signal a shared fronting service), the signed-certificate-timestamp showing Certificate Transparency log inclusion, which makes misissuance publicly auditable, and a lifetime consistent with current caps well under 400 days. HSTS and preload status tell you plaintext links get upgraded instead of traveling in the clear.
When to Walk Away
Treat expiry, name mismatch, unknown root, or a self-signed certificate on a commercial service as stop signals, not "proceed anyway" prompts: the binding between key and name is broken, which is exactly what an on-path attacker needs. Browser pinning was removed for good reasons; short-lived, logged certificates replaced it.
Architecture Diagram
Key Takeaways
- A certificate is a CA signature binding a key to names; the handshake proves private-key possession.
- Validation builds a path to a trusted root and checks SANs, dates, EKU, and revocation -- an expired intermediate sinks valid leaves.
- DV proves name control, OV and EV add business identity checks; encryption strength is identical across classes.
- The padlock is baseline, not evidence -- read the registrable domain, SAN list, CT inclusion, and validity window instead.
- Expiry, mismatch, and unknown-issuer interstitials are stop signals; never bypass them on a credentials or payment page.