SSL/TLS Certificates: What They Are and Why Your Site Needs One

An SSL (Secure Sockets Layer) / TLS (Transport Layer Security) certificate is a digital certificate that authenticates a website's identity and enables an encrypted connection between a web server and a browser. When a site has a valid SSL certificate, its URL starts with "https://" and browsers show a padlock icon.

TLS is actually the modern, more secure successor to SSL. The term "SSL" is still widely used, but virtually all modern "SSL certificates" actually use TLS. When people say "SSL," they almost always mean TLS.

SSL certificates serve two purposes: encryption (protecting data in transit from eavesdropping) and authentication (proving the website is who it claims to be).

When your browser connects to an HTTPS website, the following happens (called the TLS handshake):

1. Client Hello: Your browser connects to the server and sends a list of supported encryption methods.
2. Server Hello: The server responds with its SSL certificate and chosen encryption method.
3. Certificate Verification: Your browser verifies the certificate is valid, not expired, issued by a trusted Certificate Authority, and matches the domain.
4. Key Exchange: The browser and server securely exchange encryption keys.
5. Encrypted Session: All subsequent data is encrypted using the agreed-upon keys.

This entire handshake happens in milliseconds — you won't notice any delay. Once established, all data between your browser and the server is encrypted, protecting it from interception.

Domain Validation (DV): The most basic type. The CA only verifies that you control the domain. Issued within minutes. Free options available through Let's Encrypt. Suitable for blogs, personal sites, and small businesses.

Organization Validation (OV): The CA verifies the organization behind the domain. Takes a few days to issue. Shows the organization name in the certificate details. Better for businesses that want to display verified identity.

Extended Validation (EV): The most rigorous validation. The CA thoroughly vets the organization's legal existence, physical address, and authorization. Historically showed the company name in the browser's address bar (this has been removed by most browsers). Primarily used by financial institutions and large enterprises.

Wildcard certificates: Cover a domain and all its subdomains (e.g., *.example.com). Useful when you have many subdomains.

Multi-domain (SAN) certificates: Cover multiple different domain names with a single certificate.

Use LookMyIP's free SSL Certificate Checker at lookmyip.com/ssl. Enter any domain to instantly see the certificate issuer, validity period, expiry date, certificate chain, supported protocols, and any issues.

In your browser: Click the padlock icon in the address bar and select "Certificate" or "Connection is secure" to view certificate details.

Command line: Use OpenSSL to inspect a certificate: echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -text -noout

Key things to check:

• Is the certificate expired or about to expire?
• Does the certificate match the domain name?
• Is the certificate chain complete?
• Is it issued by a trusted Certificate Authority?

Expired certificate: The most common issue. Set up automatic renewal (Let's Encrypt certificates auto-renew with certbot) or set calendar reminders for manually managed certificates.

Certificate name mismatch: The certificate was issued for a different domain. Ensure the certificate covers all domains and subdomains your site uses (including www and non-www versions).

Incomplete certificate chain: The server isn't sending intermediate certificates. Configure your server to include the full certificate chain.

Mixed content warnings: Your HTTPS page loads some resources (images, scripts, stylesheets) over HTTP. Update all resource URLs to use HTTPS or protocol-relative URLs.

TLS version too old: Some servers still support deprecated TLS versions (TLS 1.0, 1.1). Disable these and support only TLS 1.2 and 1.3.

Self-signed certificate: The certificate wasn't issued by a trusted CA. This is fine for development but unacceptable for production — use a proper CA like Let's Encrypt (free) or a commercial provider.

More TLS incidents come from a broken chain than from an expired certificate, and the failure has a characteristic signature: it works in your browser and fails in curl, on Android, or in your payment provider's webhook.

A browser trusts a certificate only if it can build an unbroken path from that certificate to a root it already holds. A typical path has three links:

1. Leaf certificate — issued to example.com, the one you installed.
2. Intermediate certificate — issued to the CA's signing authority by its root.
3. Root certificate — self-signed, and already present in the operating system or browser trust store.

The root is never sent over the wire; the client has it. The leaf and the intermediate must both be served by your server. Omitting the intermediate is the classic misconfiguration.

It appears to work because desktop browsers cache intermediates they have seen before, and because most clients now implement AIA fetching — following a URL in the certificate to download the missing intermediate on demand. So the developer's Chrome, which has visited a thousand sites signed by that intermediate, succeeds. Meanwhile curl, older Android, Java clients and most server-to-server integrations do not fetch, and fail outright.

Check what your server actually sends:

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

Look at the Certificate chain block at the top. You should see at least entries 0 (your leaf) and 1 (the intermediate). If only 0 appears, your chain is incomplete. Verify return code: 0 (ok) at the bottom confirms a valid path.

The fix is to install the fullchain file rather than the certificate alone. With Certbot, use fullchain.pem, never cert.pem. Nearly every "works for me" TLS bug is that one-line distinction.

Since browsers capped certificate lifetimes — 398 days, dropping to 47 days under the CA/Browser Forum schedule agreed in 2025 — manual renewal has stopped being viable. Automation is no longer optional.

Let's Encrypt certificates last 90 days and Certbot renews at 30 days remaining. Installing it is not the same as verifying it works:

sudo certbot renew --dry-run

That runs the full renewal path against the staging environment without consuming rate limits. If it passes, renewal is genuinely wired up. If you have never run it, you do not know whether your renewal works — you know only that it has not failed yet.

Three failure modes cause most renewal outages:

The reload hook is missing. Certbot writes new files but nginx or Apache keeps serving the old certificate from memory until reloaded. Add a deploy hook:

sudo certbot renew --deploy-hook "systemctl reload nginx"

The HTTP-01 challenge is blocked. Renewal requires /.well-known/acme-challenge/ to be reachable over plain HTTP. A redirect rule that forces every request to HTTPS, or a firewall that closed port 80 during a security review, breaks it silently months after setup. Exempt that path explicitly.

A wildcard needs DNS-01. Wildcard certificates cannot use HTTP validation. They require a DNS TXT record, which means your DNS provider must have an API and Certbot must have credentials for it. Those credentials expire.

Regardless of automation, monitor expiry independently. Automation that fails silently is worse than no automation, because nobody is watching. Check the current expiry with:

echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

or run the domain through the SSL certificate checker on a schedule.

Browser TLS errors are deliberately vague. Mapping them to causes saves a lot of guessing.

One point about names: the Common Name field has been deprecated for over a decade. Modern clients read only the Subject Alternative Name extension. A certificate with example.com in the CN but not in the SAN list will be rejected by every current browser. When reissuing, list every hostname — including www — as a SAN.

Note also that a certificate covers hostnames, not ports or protocols. The same certificate is valid for https://example.com, https://example.com:8443 and an IMAP service on the same name. Wildcards cover exactly one label: *.example.com matches api.example.com but not example.com itself or v2.api.example.com.

Are paid certificates more secure than free ones?

No. The encryption is identical — the same algorithms, the same key sizes. What you buy with a paid certificate is a longer validity period on some products, a warranty that almost never pays out, organisational validation that appears only if someone inspects the certificate, and support. For encrypting traffic, a Let's Encrypt certificate is exactly as strong.

Do I still need Extended Validation certificates?

Browsers removed the green address bar treatment for EV certificates in 2019 because studies showed users did not notice or understand it. EV still has niche value in regulated industries where the organisational identity is checked programmatically, but for a normal website it buys nothing a user will ever see.

What is the difference between SSL and TLS?

SSL is the obsolete predecessor. All SSL versions are deprecated and disabled — SSL 3.0 was broken by POODLE in 2014. Everything in use today is TLS, currently 1.2 and 1.3. The word "SSL" persists purely out of habit, including in the name of this tool.

Should I disable TLS 1.0 and 1.1?

Yes. All major browsers removed support in 2020, and PCI DSS has required TLS 1.2 minimum since 2018. Leaving them enabled adds attack surface and will fail a security audit. Enable TLS 1.2 and 1.3 only.

Why does my certificate work on desktop but fail on an old Android phone?

Almost certainly the missing-intermediate problem, since older Android does not perform AIA fetching. It can also be an expired root: devices that stopped receiving updates before 2021 do not have the ISRG Root X1 certificate that Let's Encrypt now chains to.