“SSL” is the name everyone uses, but the protocol actually in use today is TLS (Transport Layer Security), mostly versions 1.2 and 1.3. A certificate does two jobs: it proves to the browser that the server really belongs to the domain in the address bar, and it enables an encrypted connection so nobody in between can read or alter the traffic. Without one, browsers show “Not secure” and many features (geolocation, service workers, HTTP/2 in practice) don’t work.
How a certificate works, briefly
- Your server holds a private key and a certificate containing the matching public key and your domain name(s).
- A certificate authority (CA) signs the certificate after checking you control the domain.
- During the TLS handshake the browser checks the signature against CAs it trusts, checks the domain name and expiry date, and then negotiates encryption keys.
The certificate is usually delivered with one or more intermediate certificates that link it to a trusted root. That bundle is called the chain, and serving it incompletely is a common error.
Certificate types: DV, OV and EV
| Type | What the CA verifies | Typical use | Cost |
|---|---|---|---|
| DV – Domain Validated | Control of the domain only | Blogs, business sites, shops | Free (Let’s Encrypt, ZeroSSL, Cloudflare) to low |
| OV – Organisation Validated | Domain + that the organisation legally exists | Corporate sites, some B2B requirements | Paid |
| EV – Extended Validation | Stricter organisation checks | Banks, large enterprises | Paid, highest |
Modern browsers no longer show the company name in a green bar for EV, so for most sites DV is the sensible choice. Separately, certificates can cover:
- a single name (
example.com, usually withwwwincluded), - multiple names (SAN / multi-domain),
- a wildcard (
*.example.com, one level of subdomains; requires DNS validation with Let’s Encrypt).
Free certificates with Let’s Encrypt
Let’s Encrypt is a non-profit CA that issues free DV certificates automatically via the ACME protocol. Most hosts (cPanel AutoSSL, Plesk, managed WordPress hosts) and CDNs like Cloudflare set it up with one click. On your own server, a client such as Certbot handles issuance and renewal:
sudo certbot --nginx -d example.com -d www.example.com
Let’s Encrypt certificates currently last 90 days and renew automatically around 30 days before expiry. The organisation has announced a move to 45-day certificates by February 2028, with a 64-day step in February 2027. Industry rules are heading the same way: the maximum lifetime for any public certificate dropped to 200 days on 15 March 2026, will drop to 100 days in 2027 and to 47 days in 2029. The takeaway: manual renewal is no longer realistic. Automate it and monitor it.
Common SSL errors and how to fix them
Certificate expired (ERR_CERT_DATE_INVALID)
Renewal failed silently, often because DNS moved, a firewall blocks the validation request, or the cron job stopped. Renew manually, then fix the automation. Also check the visitor’s clock: a wrong system date produces the same error.
Name mismatch (ERR_CERT_COMMON_NAME_INVALID)
The certificate doesn’t cover the exact hostname requested, e.g. it’s valid for example.com but someone visits www.example.com or shop.example.com. Reissue the certificate including every hostname you use.
Incomplete chain
Desktop browsers may cope by fetching missing intermediates, but Android devices, API clients and payment gateways often fail. Install the full chain file (on nginx, fullchain.pem, not cert.pem). Our SSL checker shows whether the chain is complete and when the certificate expires.
Mixed content
The page is HTTPS but loads some resources over http://. Browsers block mixed scripts outright and may block or upgrade images. Fix by:
- updating hard-coded URLs in the database (e.g. a search-and-replace in WordPress),
- using relative or
https://URLs in themes, - adding the header
Content-Security-Policy: upgrade-insecure-requestsas a safety net.
Self-signed or untrusted certificate
Fine for internal testing, never for a public site. Replace it with a certificate from a trusted CA.
Redirecting HTTP to HTTPS
Once the certificate works, every HTTP request should go to HTTPS with a single 301 redirect. On Apache (.htaccess):
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
On nginx:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}
Use the redirect checker to confirm http://, http://www. and https://www. each reach the final URL in one hop. Chains of two or three redirects waste time and crawl budget; see our guide to 301 vs 302 redirects.
HSTS
After HTTPS has worked reliably for a while, add HSTS so browsers never try HTTP again:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Be careful with includeSubDomains and the preload list: every subdomain must support HTTPS first, and preloading is hard to undo.
Monitoring renewals
With certificate lifetimes shrinking, a silent renewal failure becomes a visible outage much sooner. A few safeguards:
- Use your host’s or CDN’s managed certificates where possible; they renew without your involvement.
- If you run Certbot or another ACME client, check that its timer or cron job is active and test renewal with
certbot renew --dry-run. - Newer ACME clients support ARI (ACME Renewal Information), which lets the CA tell the client when to renew, for example ahead of a mass revocation.
- Set up an external expiry alert at 14 and 7 days, or periodically run your domain through an SSL checker.
- Remember certificates on things other than the website: mail servers, APIs, admin panels and load balancers.
SSL checklist
- Certificate from a trusted CA covering every hostname you use (root,
www, subdomains). - Full chain installed; TLS 1.2 and 1.3 enabled, older versions disabled.
- Automated renewal in place and expiry monitoring set up.
- All HTTP and
www/non-wwwvariants 301-redirect to one canonical HTTPS URL in a single hop. - No mixed content warnings in the browser console.
- If you use CAA DNS records, they allow your CA.