SSL Certificates Explained: Types and How They Work

What Is SSL/TLS?

SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) are cryptographic protocols that encrypt the connection between a web browser and a server. When you see the padlock icon in your browser's address bar and the URL starts with https://, it means SSL/TLS is protecting the data flowing between you and the website.

Although the industry moved from SSL to TLS years ago, the term "SSL certificate" has stuck around in common usage. When people say "SSL certificate," they almost always mean a TLS certificate. The two terms are used interchangeably, even though TLS is the actual protocol in use today.

How the HTTPS Handshake Works

Every time your browser connects to an HTTPS website, a process called the TLS handshake takes place before any data is exchanged. Here's what happens in simplified terms:

1. Client Hello — Your browser sends a message to the server saying "I'd like to connect securely" along with a list of supported TLS versions and cipher suites.
2. Server Hello — The server responds with its chosen TLS version and cipher suite, and sends its SSL certificate.
3. Certificate Verification — Your browser checks the certificate against its list of trusted Certificate Authorities (CAs). It verifies the certificate hasn't expired, the domain name matches, and the chain of trust is intact.
4. Key Exchange — Both parties agree on a shared session key using asymmetric encryption. This key will be used to encrypt all subsequent communication.
5. Secure Connection — The handshake is complete. All data exchanged from this point is encrypted with the session key using fast symmetric encryption.

With TLS 1.3, this handshake is streamlined to just one round trip (down from two in TLS 1.2), making HTTPS connections noticeably faster. You can check which TLS version your server uses with our SSL Checker tool.

Certificate Types: DV, OV, and EV

SSL certificates come in three validation levels, each representing a different degree of identity verification by the Certificate Authority.

Domain Validated (DV)

DV certificates are the simplest and most common type. The CA only verifies that you control the domain — typically by checking a DNS record or responding to an email. They're issued in minutes, often for free, and are perfectly suitable for most websites. If you're running a blog, portfolio, or small business site, a DV certificate is all you need.

Organisation Validated (OV)

OV certificates require the CA to verify that your organisation legally exists. This involves checking business registration documents and sometimes making a phone call. The process takes a few days. OV certificates display the organisation name in the certificate details, which can provide additional trust for business websites.

Extended Validation (EV)

EV certificates undergo the most rigorous validation process. The CA verifies legal, physical, and operational existence of the organisation. These were once considered essential for e-commerce sites because browsers displayed a green address bar with the company name. Most modern browsers no longer show this visual distinction, which has reduced the practical advantage of EV certificates.

Free vs Paid Certificates

Let's Encrypt revolutionised the SSL landscape by offering free, automated DV certificates. Today, there is no security difference between a free Let's Encrypt certificate and a paid DV certificate from a commercial CA — the encryption is identical. Both use the same cryptographic standards and are trusted by all major browsers.

Paid certificates still make sense in specific situations: if you need OV or EV validation, if you want a warranty or dedicated support, or if your organisation requires a specific CA for compliance reasons. For the vast majority of websites, though, a free Let's Encrypt certificate provides excellent security at no cost.

Wildcard and Multi-Domain Certificates

A wildcard certificate covers a domain and all its subdomains at one level. For example, a wildcard for *.example.com would cover www.example.com, shop.example.com, and api.example.com — but not sub.api.example.com. Wildcards simplify management when you run many subdomains.

Multi-domain (SAN) certificates use Subject Alternative Names to cover multiple completely different domain names under a single certificate. This is useful if your organisation operates several websites and you want to manage them with one certificate.

How to Check Your Certificate

You can click the padlock icon in your browser to view basic certificate details, but this only tells part of the story. Our SSL Checker gives you a complete picture — certificate validity, expiry date, the full certificate chain, TLS version support, cipher suites, and HSTS configuration. It's the same analysis you'd get from a paid security audit, but instant and free.

For ongoing monitoring, consider pairing SSL Checker with tools like Site Speed Check to ensure your TLS configuration isn't adding unnecessary latency, and Broken Link Finder to catch any mixed-content issues where HTTP resources are loaded on HTTPS pages.

Why Every Site Needs HTTPS

HTTPS is no longer optional. Here's why:

• Security — HTTPS encrypts all data in transit, protecting login credentials, payment details, and personal information from interception.
• SEO — Google has used HTTPS as a ranking signal since 2014. Sites without HTTPS are at a measurable disadvantage in search results.
• Trust — Modern browsers label HTTP sites as "Not Secure." This warning alone is enough to drive visitors away from your site.
• Compliance — Regulations like GDPR and PCI DSS require encryption of data in transit. HTTPS is the baseline for compliance.
• Modern Features — Many web APIs (geolocation, service workers, HTTP/2) require HTTPS. Without it, you're locked out of modern web capabilities.

If your site still runs on HTTP, the good news is that migrating to HTTPS has never been easier. Most hosting providers offer one-click SSL installation, and Let's Encrypt makes certificates free. There's no reason not to make the switch today.

What's Actually Inside a Certificate

A certificate is a structured data file in the X.509 format. If you open one (most platforms have a "view certificate" option), you'll see a handful of fields that all do specific jobs:

• Subject — Identifies who the certificate is for. Includes a Common Name (CN) and, for OV/EV certs, organisation details. Modern browsers ignore the CN entirely; what they actually check is the Subject Alternative Name list (see below).
• Subject Alternative Name (SAN) — The list of hostnames the certificate is valid for. Browsers check this list against the URL the user typed; a mismatch produces a hostname error.
• Issuer — Identifies the CA that signed the certificate (e.g., "Let's Encrypt", "DigiCert"). Used to find the next certificate in the chain.
• Validity Period — A "not before" and "not after" timestamp pair. The certificate is only valid between those two moments. Outside the window, browsers reject it.
• Public Key — The public half of an asymmetric keypair. Anyone can use it to encrypt data the server can decrypt; nobody can use it to impersonate the server.
• Signature — A cryptographic signature from the issuer over all the above, produced with the issuer's private key. Anyone with the issuer's public key (in the next certificate up the chain) can verify it.
• Extensions — Additional fields including Key Usage (what the key is allowed to do), Authority Information Access (where to find the issuer's cert and OCSP), and Certificate Transparency timestamps.

When you run a domain through SSL Checker, the report shows each of these fields parsed out — so you can see exactly which hostnames are covered, who issued the cert, and how long until it expires.

How a Certificate Becomes Trusted

A leaf certificate is just a small file on a web server. What makes a browser trust it is a chain of cryptographic signatures that ultimately ends at a root certificate the browser already trusts. The chain works like this:

1. The leaf certificate (your website's cert) is signed by an intermediate certificate.
2. The intermediate certificate is signed by a root certificate.
3. The root certificate is in the browser's trust store, shipped with the OS or browser itself.

To verify the leaf, the browser walks up the chain: it uses the intermediate's public key to verify the leaf's signature, then uses the root's public key to verify the intermediate's signature, then matches the root against its trust store. If every signature checks out and the root is trusted, the leaf is trusted.

Why the multi-step process? Roots are precious — compromising a root would let an attacker forge any certificate. So root keys are kept offline and used only to sign a small number of intermediates. Intermediates do the day-to-day signing of leaf certificates. If an intermediate ever gets compromised, only that intermediate's certs need to be revoked — the root stays safe.

This is why "missing intermediate" is the most common SSL misconfiguration. The leaf alone doesn't carry enough information for browsers to walk the chain — without the intermediate, the chain is broken and the cert appears untrusted, even though everything else is fine.

Common Mistakes When Setting Up SSL

Most SSL problems we see come from a small number of recurring mistakes:

• Installing the leaf without the intermediate. Use the "fullchain" file your CA provides, not the bare cert. Mobile browsers and many API clients fail otherwise.
• Manual renewal without reminders. Forgotten renewals are the leading cause of unexpected expiry. Automate via Certbot or your hosting platform; if you must do it manually, set reminders at 30, 14, and 7 days out.
• Mixing HTTP and HTTPS resources. Loading http:// images, scripts, or stylesheets on an HTTPS page triggers mixed-content warnings. Update everything to HTTPS or use protocol-relative URLs.
• Missing apex coverage on wildcards. A *.example.com wildcard does not cover example.com. Issue both as SANs.
• Outdated TLS configuration. Servers untouched for years often still allow TLS 1.0 and 1.1, which modern browsers refuse. See our TLS 1.2 vs 1.3 guide.
• Reusing private keys after revocation. If a key was compromised and revoked, generate a new keypair — don't reuse the old one.

Almost every one of these is detected automatically by SSL Checker. A 10-second scan after every install or renewal saves hours of debugging later.

Where to Go from Here

This guide covered the fundamentals — the protocol, the validation tiers, the certificate types, and the most common mistakes. From here, the next things worth understanding are:

• TLS 1.2 vs TLS 1.3 — what changed in the latest protocol version and how to enable it.
• Wildcard vs SAN vs single-domain certs — choosing the right cert scope for your site.
• Let's Encrypt vs paid certificates — when free is enough and when paying is justified.
• How to install an SSL certificate — practical install instructions for nginx, Apache, and cPanel.
• HSTS explained — locking your domain to HTTPS-only.
• SSL/TLS glossary — every term defined in plain English.

Or just run a check on a domain you care about. SSL Checker shows everything in this article in action — chain, TLS versions, expiry, SANs — and tells you exactly what's working and what isn't.