What is an SSL certificate?

When you visit a site over HTTPS, your browser and the server agree to encrypt everything they send each other. Encryption on its own is not enough, though: encrypting your password is no help if you are encrypting it for an impostor. Before anything sensitive is exchanged, the browser needs an answer to a simple question — is this server really the one that is allowed to answer for this domain?

An SSL certificate is how the server answers. It is a small, digitally signed file that binds a domain name to a public key. In effect it says: “the holder of this key is entitled to serve example.com, and a certificate authority has verified that.” If the signature checks out and the details match, the browser proceeds and shows the page. If not, you get a full-screen warning instead.

Strictly speaking, these files are X.509 certificates used by TLS, the protocol that replaced SSL more than two decades ago. The name “SSL certificate” has simply outlived the protocol it came from — the certificates themselves were never SSL-specific. We keep the familiar name here; the history is covered in SSL vs TLS.

What a certificate contains

Open any certificate — your browser will show it if you click the padlock or tune icon — and you will find the same handful of fields:

• Subject — who the certificate is for. For most certificates this is just a domain name; business-validated certificates also carry an organisation name.
• Subject Alternative Names (SANs) — the full list of domain names the certificate covers. This is the list browsers actually check; a certificate can cover one name, dozens, or a whole wildcard such as *.example.com. More on this in wildcard vs SAN certificates.
• Issuer — the certificate authority (CA) that signed it, such as Let’s Encrypt, DigiCert or Sectigo.
• Validity dates — a “not before” and “not after” timestamp. Outside that window the certificate is worthless, which is why expiry matters so much.
• The public key — the cryptographic half the server proves ownership of during the TLS handshake. Today that is typically an RSA 2048-bit key or an elliptic-curve P-256 key.
• A signature — the CA’s own cryptographic signature over all of the above, which is what makes the certificate more than a self-declaration.

Who issues certificates — and why browsers believe them

Anyone can create a certificate; creating one that browsers trust is the hard part. Trust comes from certificate authorities: organisations whose root certificates are shipped inside browsers and operating systems. Apple, Google, Microsoft and Mozilla each maintain a root programme with strict rules — audits, issuance standards, revocation duties — and CAs that break the rules get removed, which has happened to household names.

Before issuing a certificate for your domain, a CA must verify you control it. For the common domain-validated (DV) certificate this is automated: you prove control by serving a challenge file over HTTP or publishing a DNS record. Organisation-validated (OV) and extended-validation (EV) certificates add checks on the legal entity behind the domain, but they encrypt nothing extra — browsers stopped giving EV any special UI years ago. For most sites, a free DV certificate from Let’s Encrypt is exactly as secure in transit as a paid one.

The chain: leaf, intermediates, root

CAs do not sign your certificate with their precious root key directly. The root signs an intermediate certificate, and the intermediate signs yours — the leaf. When a browser verifies your site, it walks this chain: leaf → intermediate(s) → a root it already holds in its trust store. Every link must be valid for the whole chain to hold.

This design keeps root keys offline and rarely used, and it is also behind one of the most common real-world misconfigurations: a server that sends only its leaf certificate and not the intermediates. Modern browsers often repair the gap silently by fetching or caching the missing intermediate, so the site “works in Chrome” — while older Android phones, mail servers, payment clients and curl refuse to connect. Our SSL checker reports the chain the server actually presents, so an incomplete chain shows up even when your own browser hides it.

What the browser checks, in order

1. Dates — is now between “not before” and “not after”?
2. Name — does the domain in the address bar appear in the SAN list (exactly, or via a wildcard)?
3. Chain — does every signature verify, up to a trusted root?
4. Revocation and policy — has the certificate been revoked, and does it meet current rules (key size, signature algorithm, lifetime)?

Fail any one of these and the browser shows an error page rather than the site — each failure has its own error code, decoded in common SSL errors explained.

What certificates do not do

A valid certificate means the connection is encrypted and the server controls the domain name. It says nothing about whether the site is honest — a phishing site can have a perfectly valid certificate for its own look-alike domain. The padlock means “private line to this domain”, not “this domain is good”. That distinction is why browsers have quietly de-emphasised the padlock icon itself.

Check one now

The quickest way to make all of this concrete is to look at a real certificate. Run your own domain through the SSL checker — you will get a plain-English verdict, an expiry countdown, and (in Tech mode) the SAN list, chain and fingerprints discussed above. If you only care about the renewal date, the expiry checker leads with the countdown.