What a Certificate Actually Is
A TLS certificate is a signed statement binding a public key to an identity (a domain name, and sometimes an organization). It solves the one problem encryption alone cannot: knowing that the key you are encrypting to actually belongs to example.com and not to someone sitting between you and it.
The format is X.509 v3, encoded in ASN.1 DER and usually shipped as Base64-wrapped PEM — the familiar -----BEGIN CERTIFICATE----- block. "SSL certificate" is the surviving marketing name; the SSL protocol itself has been obsolete since the 1990s and everything today is TLS (1.2 or 1.3), but the certificates are the same objects either way.
Crucially, a certificate contains no secrets. It is public by design — served to every client that connects, and logged publicly in Certificate Transparency logs. The secret half is the private key, a separate file that never leaves your server. The certificate proves the identity; possession of the private key proves you are that identity.
The Fields That Matter
Decode any certificate and the same X.509 fields do the real work:
- Subject — who the certificate is for. For most modern certs this is just a Common Name (CN) like
example.com; browsers actually ignore the CN and rely on the SAN list. - Subject Alternative Names (SAN) — the list of DNS names (and optionally IPs) the certificate is valid for. This is the field browsers check against the URL. A cert can cover many names:
example.com,www.example.com,api.example.com. - Issuer — the Certificate Authority (CA) that signed it, e.g. a Let's Encrypt or DigiCert intermediate.
- Validity (Not Before / Not After) — the exact window in which the cert is trusted. Expiry is the number-one cause of certificate outages.
- Public key — typically ECDSA P-256 or RSA-2048; the key clients will use in the handshake.
- Signature — the CA's cryptographic signature over all of the above. If any byte of the certificate changes, the signature no longer verifies.
- Extensions — Key Usage and Extended Key Usage (what the cert may be used for), Basic Constraints (whether it may act as a CA), and the CRL/OCSP endpoints used for revocation checking.
When you paste a certificate into a decoder, these are the fields to read first: does the SAN list contain the hostname you are serving, and is today inside the validity window? Those two checks resolve most incidents.
The Chain of Trust
No browser has ever heard of your certificate specifically. Trust is transitive, flowing down a chain:
- Root CA certificate — self-signed, distributed inside operating systems and browsers. Roots are kept offline and used only to sign intermediates.
- Intermediate CA certificate(s) — signed by the root, these do the day-to-day signing of customer certificates.
- Leaf (end-entity) certificate — yours, signed by an intermediate.
During the handshake your server must send the leaf plus every intermediate. The client walks the chain: verify the leaf's signature with the intermediate's public key, verify the intermediate with the root's key, and check the root is present in its local trust store. A missing intermediate is the classic "works in Chrome, fails from curl and mobile apps" bug — Chrome caches and fetches intermediates aggressively, while stricter clients require the server to present the complete chain itself.
This design also explains revocation and distrust events: when a CA misbehaves, browsers remove or distrust its roots, and every certificate under them fails at once — regardless of the individual sites' behavior.
DV, OV, EV, Wildcards and SANs
Certificates differ in what was verified before issuance, not in encryption strength — a free DV cert and a $500 EV cert negotiate exactly the same TLS ciphers:
- DV (Domain Validated) — the CA verified control of the domain only, via a DNS record or HTTP challenge. Fully automated, issued in seconds, free from Let's Encrypt, ZeroSSL, and Google Trust Services. The overwhelming majority of the web runs on DV.
- OV (Organization Validated) — adds manual verification of the legal entity, which appears in the Subject. Common in enterprise and B2B compliance checklists.
- EV (Extended Validation) — the most rigorous vetting tier. Browsers dropped the green-bar EV UI years ago, so its practical value today is mostly policy-driven.
Orthogonal to validation level is coverage: a wildcard certificate (*.example.com) covers all first-level subdomains — but not the bare apex and not nested subdomains like a.b.example.com — while a SAN certificate enumerates specific names. Wildcards require DNS-01 validation, which means giving your certificate automation access to DNS.
Shrinking Lifetimes and Automation
Maximum certificate validity has been falling for a decade: from multi-year certificates, to 398 days, to 200 days as of March 2026, dropping to 100 days in 2027 and 47 days in March 2029 under the schedule adopted by the CA/Browser Forum. The rationale: certificates are bearer instruments, revocation checking is unreliable in practice, and short lifetimes shrink the window in which a stolen key or mis-issued certificate is useful.
The operational consequence is blunt: manual certificate renewal is dead. At 47-day lifetimes, renewal happens roughly every month — nobody is doing that from a calendar reminder. The ACME protocol (RFC 8555), which Let's Encrypt pioneered, is the standard answer: an agent (certbot, acme.sh, Caddy, or your cloud provider's built-in management) proves domain control, fetches, and installs certificates automatically. If any certificate in your estate is still renewed by hand, the fix is automation, not a better reminder system.
Debugging the Five Errors You Will Actually See
Nearly every certificate incident is one of these:
- Expired certificate — check Not After; the fix is renewal plus automation so it cannot recur. Watch for stale certificates cached in load balancers and CDNs after renewal.
- Hostname mismatch — the SAN list does not contain the name in the URL. Common after adding a new subdomain or accessing a server by IP.
- Incomplete chain — works in some clients, fails in others; the server is not sending intermediates. Concatenate the full chain (most CAs ship a
fullchain.pem). - Untrusted root / self-signed — the chain terminates in a root the client does not have: a self-signed cert, an internal CA not deployed to the client, or a corporate TLS-interception proxy.
- Clock skew — the client's clock is wrong, so a valid certificate appears not-yet-valid or expired. Frequent on embedded devices and VMs restored from snapshots.
# Full handshake view: chain, SANs, validity
openssl s_client -connect example.com:443 -servername example.com </dev/null \\
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName
# Check an expiry date quickly
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \\
| openssl x509 -noout -enddate
# Decode a local PEM file
openssl x509 -in cert.pem -noout -text