Dev.to Security 🔐 Cybersecurity Thu, 12 Nov 2026 08:07:27 +0000 👁 0 📖 5 min read

Six TLS certificate myths that cause outages (and one that just wastes money)

Certificate problems are one of the most embarrassing kinds of outage. The site is running, the servers are healthy, the code is fine, and every visitor gets a full-page browser warning. Nobody can get past it, and the f

Automated issuance made certificates much easier. It also created a new set of assumptions. Here are the ones I see behind most certificate incidents.

Myth 1: "We use automatic renewal, so certificates can't expire"

Automatic renewal is excellent, and it fails silently in all sorts of ways:

The renewal job runs on a server that was decommissioned, or in a container that no longer exists.
The HTTP challenge fails because someone added a redirect, a WAF rule, or basic auth in front of /.well-known/acme-challenge/.
A DNS challenge fails because the API token for the DNS provider was rotated or expired.
Renewal succeeds, but the web server is never reloaded, so it keeps serving the old certificate from memory.

That last one is particularly sneaky: the file on disk is fresh, so anyone who checks the file thinks everything is fine.

What's true: automation reduces the chance of expiry; it doesn't remove the need to check. Monitor the certificate as served, from outside, and alert well before expiry, at least two to three weeks for automated certificates so you have time to fix a broken renewal.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate -issuer -subject

Myth 2: "If it works in my browser, the certificate is fine"

Browsers are forgiving in ways other clients aren't. The classic example is an incomplete certificate chain: the server sends its own certificate but not the intermediate. Many desktop browsers can fetch or cache the missing intermediate, so the site looks fine. Older Android devices, curl, many API clients, payment provider webhooks and monitoring tools may fail.

What's true: test with a strict client. curl -v https://example.com will fail on a broken chain where your browser might not. Online TLS testers will also report chain issues explicitly. Always deploy the full chain file your certificate authority provides, not just the leaf certificate.

Myth 3: "One certificate covers the whole domain"

A certificate for example.com does not cover www.example.com. A wildcard for *.example.com covers api.example.com but not example.com itself, and not v2.api.example.com, because wildcards only match one label.

What's true: list every hostname you serve, including the bare domain, www, API hosts, status pages and anything customers might type, and confirm each one is in the certificate's Subject Alternative Names:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

Myth 4: "Our CDN handles certificates, so our origin doesn't matter"

Your CDN probably does manage the certificate visitors see. But depending on your configuration, the CDN also connects to your origin over TLS, and may validate the origin's certificate. When the origin certificate expires, visitors may see a CDN error page instead of a browser warning. Different symptom, same outage.

What's true: know which TLS mode your CDN uses to reach the origin. If it validates the origin certificate (which it should for security), monitor that certificate too, using the origin hostname or by connecting directly to the origin IP with the right SNI:

curl -v --resolve example.com:443:203.0.113.10 https://example.com/

Myth 5: "Certificate expiry is the only thing that can go wrong"

Expiry is the most common problem, not the only one. Others that cause real outages:

Hostname mismatch after adding a new domain or moving a service behind a different load balancer.
Wrong certificate served because SNI isn't configured and a default certificate is returned.
Old TLS versions or ciphers disabled on the server while some clients (older devices, embedded systems, some corporate proxies) still need them, or the reverse: a client library that doesn't support what the server now requires.
Pinned certificates in mobile apps or IoT devices that break when the certificate or its key changes.
Clock problems on clients or servers that make a valid certificate look not-yet-valid or expired.

What's true: a useful certificate monitor checks expiry, hostname match and chain validity, and ideally alerts on unexpected changes in issuer or key.

Myth 6: "We'll notice quickly if it breaks"

You might not. If the expired certificate is on an API used only by a partner, a webhook endpoint, a staging domain someone demos from, or the mail server, nobody may open it in a browser for days. Meanwhile, integrations fail with errors that look like network problems.

What's true: monitor every TLS endpoint that something depends on, not just the main website. Include non-HTTP services that use TLS, like SMTP with STARTTLS, IMAP or database connections, where relevant.

Myth 7 (the money one): "Paid certificates are more secure"

For a standard website, a free domain-validated certificate provides the same encryption as a paid one. Paid certificates may come with organisation validation, support, warranties, or fit procurement requirements, and some organisations have good reasons to buy them. But "the padlock is stronger" isn't one of those reasons, and browsers no longer display extended validation details prominently in the address bar.

What's true: choose based on your operational needs (automation support, validation type, compliance), not on assumed encryption strength.

A minimal certificate checklist

[ ] Every hostname you serve is listed somewhere, with an owner.
[ ] Each is monitored from outside for expiry, hostname match and chain.
[ ] Alert thresholds give enough time to fix a failed renewal.
[ ] Renewal is followed by an automatic reload, and that reload is tested.
[ ] Challenge paths and DNS API credentials are documented and monitored.
[ ] Origin certificates behind a CDN are covered too.

Certificate expiry and validity checks sit alongside uptime checks in upordown.online, because from a visitor's point of view, a browser warning is downtime.