SSL certificates explained: what they are and how the chain of trust works

An SSL certificate is a small signed file that binds a public key to a domain name, letting a browser verify it's talking to the real server and encrypt the traffic between them. The security you see as a padlock icon comes from a chain of digitally signed certificates running from your site up to a root certificate authority (CA) that the browser already trusts. Understanding that chain — and the difference between DV, OV and EV validation — makes it much easier to pick the right certificate and diagnose the errors when something breaks.

"SSL" (Secure Sockets Layer) is the old name; the protocol in actual use today is TLS (Transport Layer Security), currently TLS 1.3 (RFC 8446), with TLS 1.2 (RFC 5246) still common and TLS 1.0/1.1 formally deprecated (RFC 8996). The certificates themselves follow the X.509 format defined in RFC 5280. People still say "SSL certificate" out of habit, and that's fine — it means the same thing as a TLS certificate.

What is actually inside an SSL certificate?

A certificate is a structured document, not just a key. At minimum it contains:

• The subject — the domain name(s) the certificate covers, listed in the Subject Alternative Name (SAN) extension (RFC 5280 §4.2.1.6).
• The public key the server will use to establish an encrypted session.
• The issuer — which CA signed the certificate.
• A validity period — a not-before and not-after date.
• The CA's digital signature, which is what makes the whole thing verifiable.

Modern public certificates use RSA keys of at least 2048 bits or ECDSA keys (typically P-256), and they're signed with SHA-256 or better — SHA-1-signed certificates stopped being trusted by browsers around January 2017. You can inspect any live certificate's fields, SAN list and expiry date with our free SSL check tool rather than digging through browser dev tools.

How does the chain of trust work?

Browsers and operating systems ship with a built-in list of trusted root CAs. A root CA almost never signs your server's certificate directly — instead it signs an intermediate CA certificate, and that intermediate signs your leaf (end-entity) certificate. This is the chain of trust:

Root CA (trusted by the browser, kept offline)
  └── Intermediate CA (signs certificates day to day)
        └── Your leaf certificate (example.com)

When a browser connects to your server, your server must present the leaf certificate plus the intermediate(s) — the browser already has the root. If the intermediate is missing, most browsers will still show a trust error even though the leaf certificate itself is valid, because they can't build a path back to a trusted root. This is the single most common cause of "certificate not trusted" errors on an otherwise correctly issued certificate, and it's worth checking for specifically after any renewal or migration.

WarningA misconfigured or incomplete chain (missing intermediate) will fail in most browsers even though the certificate itself hasn't expired — always verify the full chain, not just the leaf, after installing or renewing a certificate.

DV vs OV vs EV: what's the real difference?

All three validation levels produce a certificate that encrypts traffic identically — the difference is entirely in what the CA verifies about the applicant before issuing it.

Level	What's verified	Typical issuance time	Common use
DV (Domain Validation)	Control of the domain only (DNS record, HTTP file, or email)	Minutes, often automated	Most websites, APIs, internal services
OV (Organization Validation)	Domain control plus the requesting organisation's legal identity	Days	Business sites, customer-facing apps
EV (Extended Validation)	Domain control plus rigorous, standardised identity and legal-existence vetting	Days to weeks	Financial services, high-assurance sites

A practical note: the green address bar that used to distinguish EV certificates was removed by Chrome around 2019, and other major browsers followed. EV certificates no longer get distinct visual treatment in mainstream browsers, so the main reason to choose EV today is organisational policy or compliance requirements, not a UI trust signal for visitors. DV, issued automatically via the ACME protocol (RFC 8555), is what powers most Let's Encrypt certificates and covers the overwhelming majority of sites correctly.

If you're weighing free DV certificates against a paid commercial certificate for your specific setup, we cover that trade-off in more depth in Let's Encrypt vs commercial SSL certificates: which do you actually need?

How long do SSL certificates last?

Publicly trusted certificate lifetimes have been shrinking for years, driven by the CA/Browser Forum's Baseline Requirements: from 60 months before 2015, down to 39 months in 2015, 825 days (~27 months) in 2018, and 398 days (~13 months) since September 2020. Let's Encrypt certificates last just 90 days by default and are meant to be renewed automatically, typically around the 60-day mark, rather than manually.

TipShort-lived certificates are becoming the norm industry-wide, so manual renewal is a liability — automate it, or use a dashboard that tracks expiry across every certificate you manage.

What is Certificate Transparency and why does it matter?

Certificate Transparency (CT) is a public logging system (RFC 6962, updated by RFC 9162) that records every publicly trusted certificate issued. Chrome has required CT logging for publicly trusted certificates since April 2018 — an unlogged certificate is treated as untrusted even if a legitimate CA issued it. CT logs are also a useful security tool in their own right: they let you monitor for certificates issued for your domain that you didn't request, which can be an early sign of a compromised account at a CA or registrar.

What about revocation and wildcard coverage?

If a private key is compromised, a certificate needs to be revoked before its expiry date. There are two mechanisms: Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP, RFC 6960). OCSP stapling lets the server present a signed, time-stamped OCSP response itself, which is faster and more private than the browser querying the CA directly.

One common misconception: a wildcard certificate like *.example.com covers only one level of subdomains (www.example.com, api.example.com) — it does not cover the bare apex domain example.com, and it does not cover nested subdomains like dev.api.example.com. You need additional SAN entries, or a separate certificate, for those.

Managing certificates across multiple providers

The real operational pain with SSL rarely comes from understanding the standards — it's tracking expiry dates and chain configuration across dozens of domains spread over different registrars and hosts. A certificate that quietly expires on a low-traffic staging server can still take down an integration that depends on it. InfraNest's certificate management tracks every certificate you manage, across every provider, in one dashboard, and flags upcoming expirations before they become an outage. If you're also managing the DNS records certificates depend on for validation, our DNS record types guide covers the record types CAs use for domain control validation.

Check any domain's current certificate and chain right now with our free SSL check tool, or set up automated certificate tracking with InfraNest's certificate management.