What you'll learn

  1. Quick answer
  2. How trust is established
  3. Certificate types, and which matter
  4. What each browser warning means
  5. Getting and renewing certificates
  6. Configuration beyond just having one
  7. FAQ

Quick Answer

A certificate binds a domain name to a public key and is signed by an authority the browser already trusts. The browser checks the signature chain, that the domain matches, and that it has not expired.

How trust is established

Your browser ships with a list of trusted certificate authorities — organisations it accepts signatures from. That list is maintained by the browser or operating system vendor.

When you visit a site, the server presents a certificate containing its domain name, its public key, validity dates, and a signature from an authority. The browser verifies that signature against its trusted list.

If it checks out, the browser knows the certificate was issued by an organisation that verified control of that domain. It then uses the public key to agree a session key, and traffic is encrypted from there — see hashing vs encryption.

What this proves is narrow and worth stating precisely: you are talking to whoever controls this domain, and nobody in between can read it. It says nothing about whether that party is honest, which is why a phishing site can have a perfectly valid certificate.

Certificate types, and which matter

Domain Validated (DV) — the authority confirms you control the domain, usually by having you serve a file or add a DNS record. Issued in seconds, free from Let's Encrypt, and cryptographically identical to the expensive kinds.

Organisation Validated (OV) and Extended Validation (EV) — the authority additionally verifies the legal organisation. EV once produced a green bar with the company name; browsers removed that display years ago because studies showed users did not notice or understand it.

Since the visual difference is gone and the encryption is the same, DV is the right answer for almost everyone. Paying for EV buys assurance that no user will ever see.

Two variants worth knowing: a wildcard certificate covers *.example.com, useful with many subdomains, and a SAN certificate lists several specific domains.

What each browser warning means

  • Expired. The most common, and almost always an operational failure rather than an attack — renewal automation stopped working and nobody noticed.
  • Name mismatch. The certificate is for a different domain — frequently a certificate covering example.com served for www.example.com, which are distinct names and must both be listed.
  • Untrusted issuer. Signed by an authority not in the trust store, including self-signed certificates. Fine on a development machine, never acceptable in production.
  • Incomplete chain. The server sent its certificate but not the intermediate that links it to the trusted root. Notably, this often works in browsers — which cache intermediates — and fails in curl, mobile apps and server-to-server calls. A site that "works for me" and fails for an API client is usually this.

Teach users never to click through these warnings. An interception attack looks exactly like a certificate error, and that is the whole point of the warning.

Getting and renewing certificates

Certificates are free and automatable, which removed the last reason for any site to be on plain HTTP.

sudo certbot --nginx -d example.com -d www.example.com

Certbot proves domain control, obtains the certificate, configures the web server, and installs a renewal timer.

Verify renewal actually works rather than assuming:

sudo certbot renew --dry-run

Let's Encrypt certificates are valid for 90 days, deliberately short to force automation. The classic outage is renewal silently failing months earlier — a changed web server config, a firewall rule, a moved webroot — and nobody discovering it until the certificate expires, usually on a weekend.

Two defences: monitor expiry as a metric and alert well before the date, and check renewal logs occasionally. Expiry-based outages are entirely preventable and remain remarkably common, including at large companies.

Configuration beyond just having one

  • Redirect HTTP to HTTPS, then enable HSTS so browsers refuse plain HTTP for your domain in future. Start with a short max-age while testing, since it is difficult to undo.
  • Serve the full chain, including intermediates. This is what fixes the works-in-browser-fails-elsewhere problem.
  • Disable old protocols. TLS 1.2 and 1.3 only; SSL and early TLS versions have known weaknesses.
  • Watch for mixed content — a page loaded over HTTPS pulling a script over HTTP undermines the whole page, and browsers block it. See HTTP vs HTTPS.
  • Test with an external scanner, which grades your configuration and names specific weaknesses.

For internal services, a self-signed certificate or a private authority is reasonable — but distribute the root properly rather than teaching your team to click through warnings, because that habit does not stay internal.

Frequently Asked Questions

Are expensive certificates more secure? No. The encryption is identical. Paid certificates differ only in how much the authority verified about your organisation, and browsers no longer display that difference.
Why does my certificate work in the browser but fail in curl? Almost always an incomplete chain. Browsers often cache intermediate certificates and fill the gap; other clients do not. Serve the full chain.
Why are Let's Encrypt certificates only valid 90 days? To force automation. Short lifetimes mean renewal must be automatic, which is more reliable than an annual manual process people forget.
What does a certificate actually prove? That you are connected to whoever controls that domain and the connection is private. It says nothing about whether the site is honest, which is why phishing sites have valid certificates.
Is a self-signed certificate acceptable? For local development, yes. Never for public sites, since browsers cannot verify it and users get a full warning — training them to click through warnings is itself a risk.