What Is an SSL Certificate and How to Check Yours

An SSL certificate is the small digital document that turns the insecure web into the secure one. When you see a padlock in your browser, a certificate is doing two quiet jobs behind it: proving the site really owns the domain it claims, and supplying the keys that encrypt everything you send and receive. This guide explains what an SSL certificate actually is, how the chain of trust works, the different types you will encounter, and — most practically — exactly how to check and grade your own.

It pairs naturally with what is HTTPS and why your site needs it, which covers the protocol that certificates make possible.

SSL, TLS, and why the names differ

First, a quick clarification, because the terminology trips everyone up. The protocol that secures web connections was originally called SSL (Secure Sockets Layer). SSL was superseded years ago by TLS (Transport Layer Security), and every secure connection today uses TLS, not SSL. But the name "SSL certificate" stuck through sheer habit, so when people say "SSL certificate" they mean a TLS certificate. We will use the common term in this guide, but know that the technology under the hood is TLS.

What a certificate actually proves

A certificate is a signed statement that says, in effect: the holder of this private key controls this domain. It contains the domain name(s) it is valid for, a public key, the issuer (which certificate authority signed it), and validity dates (not-before and not-after). When your browser connects to a site, the server presents this certificate, and the browser checks three things: that the certificate is for the domain in the address bar, that it has not expired, and that it was signed by an authority the browser trusts. Only when all three hold does the browser proceed without warning and show the padlock.

Critically, a certificate proves identity and enables encryption — it does not vouch for the honesty of the business behind the site. A certificate confirms you are genuinely connected to example.com; it cannot tell you whether example.com is a legitimate shop or a scam. That distinction matters, and it is why judging a site's trustworthiness needs more than a padlock — see is this website safe?.

The TLS handshake, briefly

When a browser and server start an HTTPS connection, they perform a TLS handshake. In simple terms: the browser says hello and lists the cryptographic options it supports; the server responds, presents its certificate, and they agree on a cipher; using the certificate's public key (and modern key-exchange methods), they establish a shared secret without ever sending it in the clear; and from that point everything is encrypted with that shared secret. The certificate's role in the handshake is to let the browser verify the server's identity and to bootstrap the encryption. You do not need to memorise the steps, but the takeaway is useful: the certificate is the anchor of trust at the very start of every secure connection.

The chain of trust: root, intermediate, leaf

Browsers do not trust your certificate directly. They trust a small set of root certificate authorities (CAs) whose certificates ship pre-installed in operating systems and browsers. Trust then flows downward in a chain:

• The root CA is the ultimate anchor. Its private key is kept offline and heavily guarded, so it rarely signs anything directly.
• The root signs one or more intermediate certificates, which do the day-to-day work of signing customer certificates.
• The intermediate signs your site's leaf certificate (also called the end-entity certificate) — the one for your actual domain.

When a browser receives your leaf certificate, it tries to build a path from that leaf, through the intermediate, back to a root it already trusts. If it can complete the chain, the certificate is trusted. This is why a complete chain matters: your server must send not just the leaf but also the intermediate(s), or some browsers will be unable to link your certificate to a trusted root and will show an error — even though the certificate itself is perfectly valid.

Certificate types: validation level and coverage

Certificates vary along two independent axes — how much identity was verified and how many names are covered.

By validation level:

• Domain Validation (DV) — the CA only confirms you control the domain (often by a DNS or file check). Issued in minutes, frequently free. This is what most websites use.
• Organisation Validation (OV) — the CA additionally verifies that the organisation behind the domain is real.
• Extended Validation (EV) — the most rigorous vetting of the legal entity. EV no longer produces the prominent company name in the address bar it once did, which has reduced its visible appeal.

By coverage:

• Single-domain — covers one hostname (and usually its www variant).
• Wildcard — covers all first-level subdomains of a domain (*.example.com), so one certificate serves app., blog., shop. and so on.
• Multi-domain / SAN — uses the Subject Alternative Name field to cover several distinct domains in one certificate.

Here is the key point that saves money and confusion: for the strength of the encrypted connection, the validation level makes no difference. A free DV certificate encrypts exactly as strongly as an expensive EV one. You pay for identity assurance, coverage and convenience — not for better security.

Certificate aspect	Options	What it changes
Validation level	DV / OV / EV	Level of identity vetting (not encryption strength)
Coverage	Single / Wildcard / Multi-domain (SAN)	How many hostnames the one certificate secures
Cost	Free (e.g. Let's Encrypt) to paid	Validation, support, warranty — not connection security
Lifetime	Typically up to ~398 days	How often you must renew (shorter is now the trend)

How to check a certificate

There are three reliable ways, from quickest to most thorough.

1. The browser padlock and certificate viewer. Click the padlock in the address bar and choose the option to view the certificate (the exact wording varies by browser). You can see who it was issued to, who issued it, the validity dates, and often the full chain. This is the fastest sanity check: is it for the right domain, is it in date, and is the issuer a recognisable CA?

2. SSL Labs SSL Test. For a graded, in-depth assessment, run the domain through the free SSL Labs SSL Test at ssllabs.com/ssltest. It inspects the certificate, the chain, the protocol versions and cipher suites the server supports, and known weaknesses, then assigns an overall grade from A+ down to F. It is the de facto standard for checking TLS configuration and will flag an incomplete chain, weak protocols, or an expiring certificate clearly.

3. openssl s_client from a terminal. For a raw look at exactly what the server sends, run:

openssl s_client -connect example.com:443 -servername example.com

This prints the certificate chain the server is presenting and the negotiated connection details. It is the best way to diagnose a chain problem, because it shows you precisely which certificates the server is (or is not) sending. To see just the validity dates, you can pipe the output into openssl x509 -noout -dates.

Broader site audits roll this into a wider report: StackOptic, for example, surfaces HTTPS and certificate status alongside performance, SEO and security headers, so you see the certificate picture in context rather than as an isolated check. For reading the rest of what a server reveals, see how to read a website's HTTP headers.

Expiry, renewal, and automation

Every certificate has an expiry date, and an expired certificate breaks your site for every visitor with a full-page browser warning — one of the most common and most embarrassing outages there is. Certificate lifetimes have been getting shorter (the maximum is now around 398 days, and the industry is moving toward much shorter spans), which makes manual renewal increasingly impractical.

The answer is automation. Let's Encrypt, a free, non-profit certificate authority, issues DV certificates valid for 90 days and is designed to be renewed automatically by software (using the ACME protocol). Most modern hosting platforms, CDNs and web servers can obtain and renew Let's Encrypt certificates with no human involvement, so the certificate quietly renews well before it expires and you never think about it. If you are still renewing certificates by hand, moving to automated issuance is one of the highest-value reliability improvements you can make. Set a calendar reminder and automate — belt and braces — until you trust the automation.

Common certificate errors and how to fix them

Error	What it means	Typical fix
Expired certificate	Past its not-after date	Renew (and automate renewal so it never recurs)
Name mismatch	Certificate is for a different domain than the URL	Reissue for the correct hostname, or fix the redirect/host
Incomplete chain	Server is not sending the intermediate certificate	Install the full chain (leaf + intermediate) on the server
Untrusted issuer / self-signed	Signed by an authority the browser does not trust	Replace with a certificate from a trusted CA
Mixed content	Page is HTTPS but loads some assets over HTTP	Update those asset URLs to HTTPS
Weak protocol / cipher	Server allows outdated TLS versions	Disable old protocols; keep modern TLS only

A word on mixed content, because it confuses people: the certificate can be perfectly valid, but if your HTTPS page pulls in an image, script or stylesheet over plain http://, the browser may block it or downgrade the padlock to a warning. The fix is to ensure every resource the page loads is requested over HTTPS. It is a page problem, not a certificate problem, but it shows up right next to certificate trust in the browser, so it is worth knowing the difference.

How certificate health affects trust and SEO

A valid certificate is now table stakes. Browsers label HTTP pages — and pages with certificate errors — as "Not Secure", which visibly undermines trust at exactly the moment you want it. Search engines treat HTTPS as a (lightweight) positive signal, confirmed by Google back in 2014, and a broken or expired certificate that takes your site offline will obviously harm rankings far more than the signal itself ever helped. So certificate hygiene sits at the intersection of security, user trust and SEO: get it right and it is invisible; get it wrong and everyone notices at once. The security headers you layer on top — explored in HTTP security headers explained — assume a working certificate underneath, which is another reason to treat the certificate as the foundation.

A quick certificate checklist

• Confirm the certificate is valid and in date (browser padlock or SSL Labs).
• Check it is issued for the correct domain (including www and any subdomains you use).
• Verify the chain is complete (use openssl s_client or SSL Labs to be sure).
• Automate renewal (Let's Encrypt + ACME on your host or CDN) so expiry can never surprise you.
• Eliminate mixed content so the padlock stays clean.
• Run SSL Labs periodically and aim for a strong grade with only modern protocols enabled.

Go deeper

• The protocol behind it: what is HTTPS and why your site needs it.
• Harden the response: HTTP security headers explained.
• Judge a site you did not build: is this website safe?
• Read what a server reveals: how to read a website's HTTP headers.

Want HTTPS and certificate status checked alongside performance, SEO and security? Analyse any URL with StackOptic — one report, free, no sign-up.