SSL and TLS: how HTTPS works and the checks that matter

An SSL certificate is a small data file, signed by a trusted certificate authority, that proves a website really owns its domain name and lets the visitor's browser set up an encrypted HTTPS connection with it. It is what puts https:// in the address bar and stops browsers from showing a "Not secure" label or a full-page warning. This guide explains, in plain language, what a certificate is, what SSL and TLS mean, and how the two work together. Then it goes through the handful of checks that decide whether visitors see your site or a warning, and where to go for each fix.

Quick answer

• What it is: a digital ID card for a domain. It holds the domain names it covers, the site's public key, who issued it and the dates it is valid, all signed by a certificate authority that browsers trust.
• What it does: lets the browser confirm it is talking to the real site, then encrypt everything in between, so nobody on the network can read or change it.
• SSL vs TLS: SSL is the old name; every secure site today uses TLS 1.2 or 1.3. "SSL certificate" and "TLS certificate" mean the same file.
• Cost: free certificates (Let's Encrypt, most hosts, Cloudflare) encrypt exactly as well as paid ones.
• The checks that matter: not expired and renewing automatically, the full chain installed, TLS 1.0 and 1.1 off, every http:// address redirecting to https:// in one hop, no http:// files on https:// pages.
• Run the SSL checker to test all of it with a real handshake.

What is an SSL certificate?

Think of it as a passport for a website. A passport has your name, your photo and a stamp from a government that other countries trust. A certificate has your domain name (example.com, www.example.com), your server's public key, and the signature of a certificate authority (CA) that browsers trust. When a visitor opens your site, the browser checks that stamp before it shows anything.

A certificate contains:

• The names it covers: one domain, several (a SAN or multi-domain certificate), or a wildcard such as *.example.com, which covers shop.example.com and www.example.com but not example.com itself or a.b.example.com.
• The public key: half of a key pair. The matching private key stays on your server and never leaves it.
• The issuer: the certificate authority that signed it, such as Let's Encrypt, DigiCert or Sectigo.
• The validity dates: "not before" and "not after". After the second date, every browser refuses it.

Browsers trust a certificate because they, or the operating system, carry a short list of root certificates from authorities that pass regular audits (the Chrome, Mozilla, Apple and Microsoft root programs). Anything signed, through a chain, by one of those roots is trusted. Anything else, including a certificate you make yourself ("self-signed"), gets a warning.

Types of certificate: DV, OV and EV

Certificate authorities check different amounts before signing:

All three use the same encryption. For almost every site a DV certificate, often free and issued in seconds, is the right choice. Paid OV and EV certificates add a verified company name inside the certificate details, warranties and support, none of which change what visitors see.

What is SSL, and what is TLS?

SSL (Secure Sockets Layer) was the protocol Netscape created in the 1990s to encrypt web traffic. TLS (Transport Layer Security) replaced it in 1999, and every version of SSL has since been retired as insecure. The name stuck, so people still say "SSL certificate", "SSL checker" and "SSL error" when everything underneath is TLS.

The certificate is the same whichever protocol runs; what differs is which protocol versions your server agrees to speak. A server should accept TLS 1.2 and 1.3 only. The protocol side is covered below and in TLS 1.2 vs 1.3, and turning TLS 1.0 and 1.1 off.

How SSL certificates work

Every HTTPS connection starts with a TLS handshake, a short exchange before any page content moves:

1. The browser says hello: which TLS versions and encryption methods it supports, and which host name it wants (so one server can host many sites).
2. The server answers with its certificate and the intermediate certificates that link it to a trusted root.
3. The browser checks the certificate: the signatures up the chain to a root it trusts, that the name matches the address, and that today is between the two dates. If any check fails, it stops and shows a warning.
4. Both sides agree on keys: using a key exchange that the certificate's key vouches for, browser and server derive session keys that only the two of them know.
5. Everything after is encrypted: the page, form data, cookies and passwords.

With TLS 1.3 this takes one round trip between browser and server; TLS 1.2 needs two. On a modern server the whole handshake adds only milliseconds, which is why "HTTPS is slow" stopped being true years ago.

The key point for site owners: the certificate proves identity, and the handshake uses it to set up encryption. Most of what goes wrong is on the identity side (expired, wrong name, incomplete chain), and it is all visible from outside, so it can be checked. What happens during an SSL handshake goes through every step in plain language, and what is inside an SSL certificate opens the file field by field.

Why HTTPS matters for your site

Browsers treat plain HTTP as a problem. Chrome has labelled every HTTP page "Not secure" since July 2018, and from Chrome 154 in October 2026 its "Always use secure connections" setting is on by default: Chrome tries HTTPS first and warns before loading a public site that only offers HTTP. Many browser features, such as geolocation, service workers and HTTP/2 in browsers, only work over HTTPS.

For visitors it is privacy and integrity: nobody on the café Wi-Fi or at the internet provider can read what they type into your forms or inject ads into your pages. For search, Google has used HTTPS as a lightweight ranking signal since 2014, and Googlebot cannot fetch a page behind a certificate error at all.

What HTTPS does not do: it protects the connection, not the site. A phishing site can have a perfectly valid certificate. The padlock says "this is really example.com and nobody is listening", not "example.com is trustworthy".

How to check your SSL certificate

The checker performs a TLS handshake with your server, with the host name like a browser, and reads the certificate: validity dates, issuer, the names it covers and whether the chain validates against the public roots. A second handshake offers only TLS 1.0 and 1.1 to see whether the server still accepts them. The page fetch shows whether http:// redirects to https://, whether HSTS is set and whether the HTML loads anything over plain HTTP. It is a practical check of what causes browser warnings, not a full cipher-suite audit.

The fix pages behind these findings are TLS certificates, TLS versions, HTTPS and mixed content.

The checks that matter

Expiry and renewal

An expired certificate is the most visible failure on the web: every browser replaces the page with a full-page warning, NET::ERR_CERT_DATE_INVALID in Chrome, and most visitors leave. On a site that sends HSTS, the browser does not even offer "proceed anyway". It happens to large companies every year, because renewal was manual or the automation broke silently.

Certificates are getting shorter by design. Under the CA/Browser Forum rules, public certificates issued from 15 March 2026 last at most 200 days, dropping to 100 days in March 2027 and 47 days in March 2029. Let's Encrypt certificates last 90 days today; Let's Encrypt has announced 64 days from February 2027 and 45 days from February 2028. Manual renewal is no longer realistic.

On a VPS with Let's Encrypt:

sudo certbot --nginx -d example.com -d www.example.com
sudo systemctl status certbot.timer   # the timer runs twice a day and renews when due
sudo certbot renew --dry-run          # proves renewal works

Caddy, managed hosts and Cloudflare's edge certificates renew on their own. The checker warns under 30 days left and fails under 7. How each renewal stack works, the ways it fails silently, and how to hear about it first are in how to renew an SSL certificate and monitor its expiry.

The certificate chain

Your certificate is signed by an intermediate, which is signed by a root. The server must send your certificate plus the intermediates; browsers already hold the roots. When the intermediate is missing, desktop Chrome often still shows a padlock because it has fetched or remembered that intermediate before, while Android phones, curl, payment webhooks and search crawlers fail. "It works for me" is the classic symptom.

The fix is to configure the full-chain file, not the certificate alone:

ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

On Apache 2.4.8 and newer, SSLCertificateFile takes the same fullchain.pem. Test from outside:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -E "Verify return code|s:|i:"

Verify return code: 0 (ok) means the chain is complete. How to read the chain, what each error message means and the fix on every common server are in certificate chain errors and intermediate certificates.

TLS versions

Old TLS versions do not break the site, but a server that still accepts them lets a network attacker try to push a connection down to a version with known weaknesses, and payment-card rules (PCI DSS) forbid them. No supported browser needs them.

ssl_protocols TLSv1.2 TLSv1.3;

On Apache: SSLProtocol -all +TLSv1.2 +TLSv1.3. On Cloudflare: SSL/TLS → Edge Certificates → Minimum TLS Version → 1.2. Caddy already uses 1.2 as its minimum. Who might still use the old versions, and how to prove they are off, are in TLS 1.2 vs 1.3: turning legacy protocols off.

The redirect from http to https

A certificate is only useful if visitors end up on https://. Every http:// address, typed or from an old link, should answer with a 301 to the same path on https://, in one hop:

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

Keep the path ($request_uri); redirecting everything to the home page loses deep links. Both example.com and www.example.com need a valid certificate, because the redirect from one to the other only happens after the TLS handshake.

Mixed content

Mixed content is an http:// image, script or stylesheet on an https:// page. Browsers block scripts and stylesheets outright, so sliders, menus or checkout stop working, and they upgrade or flag images, which removes the padlock. It usually comes from absolute URLs in old content or a theme setting that still holds the http:// address.

The report lists every http:// resource. Fix the source (a database search-and-replace from http://example.com to https://example.com, then theme and plugin settings), and add Content-Security-Policy: upgrade-insecure-requests as a safety net. The full procedure is in mixed content: finding and fixing http:// leftovers.

HSTS

Once all of the above holds, the Strict-Transport-Security header tells browsers to use HTTPS for your site without asking, closing the gap on the very first http:// request of each later visit. It belongs to the security headers, so it is covered in HTTP security headers and in HSTS: enabling it safely.

SSL certificate errors visitors see

When a check fails, the visitor sees an error page instead of your site. The common ones map back to the checks above:

"Your connection is not private"

This is Chrome's full-page warning for any certificate the browser rejects, and the code under "Advanced" says which check failed: ERR_CERT_DATE_INVALID for an expired certificate, ERR_CERT_COMMON_NAME_INVALID for a missing name, ERR_CERT_AUTHORITY_INVALID for a self-signed certificate or a missing intermediate. Firefox and Safari show the same problem with their own wording.

If the checker shows your certificate is valid and only one visitor sees the warning, the cause is usually on their side: a wrong system clock, a Wi-Fi login page, or antivirus intercepting HTTPS. The visitor fix, the owner's fix for each code and why HSTS removes the "Proceed" link are in fixing "Your connection is not private".

ERR_SSL_PROTOCOL_ERROR

Here the handshake does not even get as far as a certificate. On the server side the usual causes are a port 443 that speaks plain HTTP (in nginx, listen 443; without ssl), a host name with no certificate configured, or a mismatched certificate and key after a renewal. A server that only accepts old protocols shows the separate ERR_SSL_VERSION_OR_CIPHER_MISMATCH in current browsers.

An openssl s_client test from outside tells you whether the server or the visitor's device is at fault. How to read its output and fix each cause is in ERR_SSL_PROTOCOL_ERROR: what it means and how to fix it.

Cloudflare errors 525 and 526

Behind Cloudflare there are two connections: visitor to Cloudflare, and Cloudflare to your server (the origin). A 525 means the second handshake failed; a 526 means the origin's certificate is invalid while the SSL mode is Full (strict). Visitors cannot fix either, and the SSL checker sees only Cloudflare's valid edge certificate, so you test the origin directly.

The fix is a valid certificate on the origin, such as a free Cloudflare Origin CA certificate, and the SSL mode set to Full (strict). Never use Flexible to make the error go away: visitors see HTTPS while Cloudflare talks to your server over plain HTTP. The diagnosis and both certificate options are in Cloudflare error 525 and 526, and the rest of the free-plan settings in Cloudflare settings for speed and security.

HTTP vs HTTPS and the "Not secure" label

HTTP sends pages as readable text; HTTPS is the same protocol inside a TLS connection, private, tamper-proof and tied to your domain by the certificate. Visitors see the difference in the address bar: HTTPS gets no label (Chrome replaced the padlock with a neutral "tune" icon in 2023), while HTTP gets "Not secure", and from Chrome 154 a warning before the page loads for public sites that only offer HTTP.

If your site says "Not secure" even though you have a certificate, one of three things is wrong: visitors reach http:// without a redirect, the page loads mixed content, or a form posts to an http:// address. The checker's redirect and mixed-content findings tell you which. The full comparison, what it means for search, and the step-by-step fix are in HTTPS vs HTTP and the "Not secure" warning.

Getting a free SSL certificate

Let's Encrypt, a non-profit certificate authority, has issued free DV certificates since 2015 and is the reason most of the web now runs on HTTPS. Most hosts, including shared hosting with cPanel's AutoSSL, managed WordPress hosts, Netlify, Vercel and Cloudflare, issue and renew free certificates automatically; you often only need to switch it on. On your own server, certbot does the same, and web servers like Caddy do it built in.

A paid certificate makes sense only when you need OV or EV details for a compliance requirement, a warranty for a contract, or a certificate for a system that cannot automate renewal. How validation works, the certbot commands, wildcards, rate limits and the WordPress steps are in Let's Encrypt: get a free SSL certificate and keep it renewing.

Platform guides

Caddy gets and renews certificates, redirects to HTTPS and uses TLS 1.2 as its minimum with no configuration; you add the headers. See Caddy: the two-line HTTPS server.

nginx and Apache: the certificate paths, protocol lines and redirects above, plus headers and caching, are assembled into one tested file in nginx configuration for an A grade and Apache .htaccess for an A grade.

Netlify and Vercel issue certificates automatically for every custom domain; what is left is headers and redirects, covered in Netlify and Vercel: the headers, caching and redirects to set.

Cloudflare: edge certificates are automatic; set SSL mode to Full (strict) with a valid origin certificate, turn on Always Use HTTPS, and set the minimum TLS version to 1.2. See Cloudflare settings for speed and security.

Checks that do not matter much

• Cipher suite grades on scanners. With TLS 1.2 and 1.3 and a current OpenSSL, the default suites are fine. Custom cipher lists cause more outages than they prevent.
• Extended Validation certificates. Browsers no longer show the company name, so EV changes nothing for visitors.
• OCSP stapling and key sizes beyond 2048-bit RSA or P-256. Current servers ship with sensible defaults, and Let's Encrypt stopped running OCSP in 2025. Not worth a project.
• The padlock as a promise. HTTPS protects the connection, not the site's honesty.

Verify

• The SSL checker shows every finding passed and 30 or more days left on the certificate.
• openssl s_client reports Verify return code: 0 (ok).
• Open the site on an Android phone and on a desktop: no warning on either.
• The redirect checker shows one 301 from http:// to the final https:// URL.
• certbot renew --dry-run, or your host's panel, confirms that renewal is automatic.

Common mistakes

• Renewing the certificate but not reloading the server. nginx and Apache keep the old one in memory until reloaded; certbot's hooks do it for you, a manual renewal does not.
• A certificate for example.com but not www.example.com, or the reverse. Both names need to be on the certificate, because the redirect happens after the handshake.
• Installing cert.pem instead of fullchain.pem. Desktop browsers look fine; phones and APIs fail.
• Blocking /.well-known/acme-challenge/ with a security rule or a redirect. Renewal fails quietly. Allow it.
• Cloudflare in "Flexible" mode. Visitors see HTTPS, but the connection to your server is plain HTTP. Use Full (strict).
• Leaving TLS 1.0 on "for compatibility". No supported browser or search engine needs it.

Questions people ask

What is an SSL certificate?

An SSL certificate is a small data file that proves a website owns its domain name and lets the browser set up an encrypted HTTPS connection. It contains the domain names it covers, the site's public key, the issuing certificate authority's signature and the validity dates. Browsers trust it because the authority is in their trust store. Without a valid one, visitors see a full-page security warning instead of your site.

What is TLS?

TLS (Transport Layer Security) is the protocol that encrypts the connection between a browser and a website; it is what the "S" in HTTPS runs on. It replaced SSL in 1999, and today servers should accept only TLS 1.2 and TLS 1.3, the version published in 2018 that is faster and drops older, weaker options. Your certificate is used during the TLS handshake to prove the site's identity.

What is an SSL certificate chain?

The chain is the path of trust from your site's certificate to a root certificate the browser already trusts: your leaf certificate, signed by one or more intermediate certificates, signed by a root. Your server must send the leaf and the intermediates; browsers hold the roots. A missing intermediate makes some devices, often Android phones, show a warning while desktop browsers look fine. See certificate chain errors.

What does SSL stand for, and is it the same as TLS?

SSL stands for Secure Sockets Layer. TLS (Transport Layer Security) is its successor, and every secure site today uses TLS 1.2 or 1.3; all SSL versions and TLS 1.0 and 1.1 are retired as insecure. The name stuck, so "SSL certificate" and "SSL checker" still mean TLS. The certificates are the same either way; what matters is which protocol versions your server accepts.

What causes an SSL certificate error?

Almost always one of four things: the certificate has expired, it does not cover the name in the address bar (often www. or a subdomain), the server does not send the intermediate certificate, or the certificate is self-signed. Less often, the visitor's device has the wrong date or security software intercepts the connection. Check your site from outside with a TLS handshake; if it passes there, the cause is on the visitor's side.

How do SSL certificates work?

A certificate authority checks that you control the domain, then signs a certificate binding the domain name to your server's public key. When a visitor connects, the server sends that certificate; the browser checks the signature chain up to a trusted root, the name and the dates, then uses the key exchange to agree on encryption keys only the two of them know. From then on, everything between browser and server is encrypted.

What is an SSL handshake?

The SSL handshake, today a TLS handshake, is the exchange at the start of every HTTPS connection in which the browser and server agree on a protocol version and cipher, the server presents its certificate, and both sides derive the keys that encrypt the rest of the conversation. With TLS 1.3 it takes one round trip; TLS 1.2 needs two. A failed handshake shows as a connection or certificate error.

How do I renew an SSL certificate?

With Let's Encrypt, renewal is automatic once certbot or your host's tool is set up: certificates last 90 days today, falling to 45 days by 2028, and renew well before expiry; certbot renew --dry-run confirms the job works. With a paid certificate, buy the renewal, create a new CSR, install the new certificate with its intermediate chain and reload the server. Then check the new expiry date.

Is a free SSL certificate as secure as a paid one?

Yes. A free certificate from Let's Encrypt or your host uses the same encryption as a paid one, and browsers show it the same way. Paid certificates add organisation validation, warranties or support, none of which visitors see, since browsers stopped displaying company names for Extended Validation. Free certificates are short-lived, so they must renew automatically; set that up once and monitor it.