Skip to content

SSL/TLS Certificates: What They Are and How They Work

Last updated August 9, 2026.

What an SSL/TLS certificate actually does

An SSL/TLS certificate is a signed file that binds a public key to a domain name. When a browser connects to your site over HTTPS, your server presents this certificate. The browser uses it to encrypt the connection and to verify it is actually talking to your domain, not an impostor sitting in the middle.

The trust chain, in short

Your certificate is signed by a Certificate Authority (CA). That CA's own certificate is usually signed by an intermediate, which chains up to a root CA that browsers and operating systems trust by default. A valid connection has to present the full chain — leaf certificate plus every intermediate — so the browser can walk it back to a trusted root. If a link is missing, some browsers show a warning even though the certificate itself is fine.

Common certificate problems

Four issues account for most certificate-related outages and browser warnings: the certificate has expired, the certificate's domain doesn't match the site it's serving (hostname mismatch), the certificate is self-signed rather than issued by a trusted CA, or the chain is incomplete. Each is easy to check for and easy to fix once identified — the hard part is noticing before a customer does.

Why this matters beyond the padlock icon

A broken certificate doesn't just show a scary browser interstitial. Search engines and uptime monitors treat a certificate failure as a site being effectively down. Expired certificates on API endpoints or subdomains can silently break machine-to-machine integrations long before anyone sees a browser warning.

FAQ

What is an SSL/TLS certificate?

A file issued by a Certificate Authority (CA) that binds a public key to a domain name and is signed by that CA. It lets a browser verify it's actually talking to the real server for that domain, and it provides the key material used to encrypt the connection.

What is a self-signed certificate, and why is it a problem?

A certificate signed by its own private key instead of a trusted CA. Browsers have no way to verify it against a known-trusted issuer, so they show a security warning — it provides encryption, but not the identity verification a real certificate provides. It's fine for local development, not for a public-facing site.

What is a certificate chain, and why does it matter?

Most certificates are signed by an intermediate CA, not the root CA directly, so the server needs to present the full chain — its own certificate plus the intermediate(s) — for a client to verify the path up to a trusted root. A server that sends its certificate without the intermediate produces an "incomplete certificate chain" error in some clients even though the certificate itself is otherwise valid.

How often should an SSL/TLS certificate be renewed?

It depends on the certificate's validity period — many free CAs like Let's Encrypt issue 90-day certificates specifically to encourage automated renewal. Whatever the period, an expired certificate breaks HTTPS for every visitor until it's replaced, so renewal should be automated rather than tracked manually.

What does "certificate hostname mismatch" mean?

The certificate presented doesn't cover the hostname the browser actually connected to — for example the certificate is issued for example.com but the site is serving www.example.com without www.example.com listed in the certificate's Subject Alternative Names. Browsers block the connection because they can't verify the certificate is actually for the site being visited.

Check your own certificate

Run a free check for expiry, hostname mismatch, self-signed certificates, and chain issues. If you want certificate health alongside headers and DNS in one pass, the full website security scanner covers all three.

Open the SSL/TLS checker