What Is an SSL/TLS Certificate?

Acutis · plain-English network help · updated June 2026

What is an SSL/TLS certificate, in plain English?

An SSL/TLS certificate is a small digital file that proves a website is really who it claims to be, and lets your browser set up an encrypted connection to it. When you see the padlock in your address bar and the site loads over https://, a certificate is doing the work behind the scenes. "SSL" is the old name; the modern protocol is actually TLS, but almost everyone still says "SSL certificate" out of habit.

The certificate does two jobs at once. First, it carries a public key the browser uses to encrypt traffic so no one in the middle can read it. Second, it carries an identity claim — "this key belongs to the operator of example.com" — that has been vouched for by a trusted third party. Encryption without that identity check would be useless, because you could be talking privately to an impostor.

What a certificate actually proves

A certificate does not prove a website is safe, honest, or well run. It proves something narrower but important: that whoever set up the connection controls the domain name on the certificate. The padlock means "your traffic to this name is encrypted and the name matches," not "this company is trustworthy."

Each certificate lists a few key facts: the hostname or hostnames it covers, the public key, who issued it, and the dates it is valid between. Your browser checks all of these every single time you connect, in a fraction of a second.

The CA and the chain of trust

Certificates are issued by a Certificate Authority, or CA — an organization your browser already trusts, such as Let's Encrypt, DigiCert, or Sectigo. Your operating system and browser ship with a built-in list of trusted CA "root" certificates. The trust flows down a chain:

• The root certificate belongs to the CA and is pre-installed and trusted by your device. Roots are kept offline and rarely used directly.
• An intermediate certificate is signed by the root and is what actually signs day-to-day website certificates. This keeps the precious root key out of harm's way.
• The site's certificate (the "leaf") is signed by the intermediate. Your browser walks the chain upward — leaf, to intermediate, to root — and trusts the site only if that chain ends at a root it already knows.

If any link in that chain is missing, expired, or untrusted, the whole connection is flagged as insecure — even if the site's own certificate is fine. A surprising number of "broken HTTPS" cases are just a server that forgot to send its intermediate certificate.

Validity dates — and why certificates expire

Every certificate has a "not before" and "not after" date. Outside that window, browsers reject it. Expiry is a deliberate safety feature, not a flaw. Short lifetimes mean that if a key is ever stolen, the damage has a built-in time limit, and it forces operators to renew regularly so old, weak certificates don't linger for years.

Lifetimes have steadily shrunk. Certificates once lasted several years; the industry maximum is now about 13 months, and free certificates from Let's Encrypt are valid for just 90 days. That sounds inconvenient, but it's designed to be automated — renewal usually runs on a schedule with no human involved. When it isn't automated, an expired certificate is one of the most common reasons a working site suddenly throws errors for every visitor.

Covered hostnames and SANs

A certificate is only valid for the exact names listed on it. Those names live in a field called the Subject Alternative Name, or SAN. A single certificate can cover several names at once — for example example.com, www.example.com, and api.example.com — by listing each one in the SAN field.

A wildcard entry like *.example.com covers any single sub-name under that domain. The important rule: if you visit a hostname that isn't on the certificate's list, the browser treats it as a mismatch and warns you, even though the certificate itself is perfectly valid for the names it does cover.

What causes browser certificate warnings

When you see a full-page "your connection is not private" warning, it's almost always one of these:

• Expired (or not-yet-valid). The current date is outside the certificate's validity window. The single most common cause — and sometimes it's your own device's clock being wrong.
• Name mismatch. The hostname you typed isn't listed on the certificate. Visiting www. when only the bare domain is covered, or hitting a server by its IP address, triggers this.
• Untrusted issuer. The certificate was signed by a CA your browser doesn't recognize — a self-signed certificate, an internal corporate CA, or a missing intermediate that breaks the chain.
• Revoked. The CA has marked the certificate as no longer valid, usually because its key was compromised.

It's worth taking these warnings seriously. They are the browser doing exactly its job — refusing to encrypt traffic to something it can't verify.

A quick word on Certificate Transparency

Every publicly trusted certificate today is also recorded in public, append-only ledgers called Certificate Transparency (CT) logs. The idea is accountability: because every issued certificate is logged in the open, a domain owner can watch for certificates issued for their name that they never asked for — an early warning of a mis-issued or fraudulent certificate. Browsers expect to see this CT proof and may distrust certificates that aren't logged.