One Morning, Your Site Is Down—And It’s Not a Hack
Monday morning. A customer tries to reach your application. Instead of the login screen, they see a full-page browser warning: “Your connection is not private.” The padlock is broken. The certificate expired at 3:47 a.m.
Sales, support, and marketing go dark. Inbound traffic crashes. Your team scrambles to find who owns the renewal—and discovers no one does. A routine certificate expiry just took your entire digital front door offline, and it will take hours to fix. This isn’t a hypothetical; expired certificates remain one of the most preventable causes of downtime for businesses running web-facing services.
The Real Fallout: More Than Just a Warning
An expired certificate doesn’t just inconvenience users. It signals that your infrastructure isn’t being actively maintained. Browsers block access—no override, no “proceed anyway” for HTTPS sites that set HSTS. APIs that depend on mutual TLS suddenly break. Email servers using STARTTLS can fail quietly, delaying critical communications.
The worst part? The expiry itself is often the symptom of a deeper problem: no one owns certificate lifecycle. But beyond expiry, the way you implement TLS introduces risks that are just as damaging. Wildcard certificates spread a single compromise across every subdomain. Missing CAA records allow any public CA to issue certificates for your domain. Self-signed certificates teach your users to ignore security warnings—a habit that attackers later exploit.
Each of these missteps lives in DNS configuration or certificate policy. They’re invisible until they bite you. A scan across your domain surface reveals exactly which ones are waiting to cause an outage. Here’s how they break, and how to fix them.
The Hidden Risks in Your TLS Setup
Expired Certificates: The Obvious Outage
The Problem
A certificate passes its notAfter date and every browser throws a CERT_DATE_INVALID error. If you rely on calendar reminders or a single team member to renew, expiry will eventually win. Subdomains used by marketing or staging that no one monitors are especially prone. Some companies lose a wildcard cert and don’t realize until it’s too late.
How to Fix It
Move renewal off a human’s to-do list. Use an automated certificate manager that monitors expiry windows and renews before the deadline, ideally via ACME. For internal or non-public services, still enforce automation. A TLS/SSL Certificates Explained walkthrough shows exactly how certificates are validated—so you understand what your automation is handling.
Wildcard Certificates: One Key for All Your Doors
The Problem
A single *.example.com certificate encrypts traffic for app.example.com, mail.example.com, staging.example.com, and a forgotten partner portal. If the private key is exposed—via a compromised server, a misconfigured web app, or a developer’s laptop—every subdomain is instantly at risk. Attackers can impersonate any service under that domain, and revoking the wildcard breaks everything at once.
How to Fix It
Limit wildcard use to cases where truly dynamic subdomains demand it. For most services, use dedicated certificates per hostname. Where a wildcard is unavoidable, store the key in a hardware security module or a secrets manager with rotation. Review all active wildcards quarterly. Learn the trade-offs in Wildcard SSL to decide where they still belong.
Missing CAA Records: Who’s Issuing Certificates for Your Domain?
The Problem
By default, any public Certificate Authority can issue a certificate for your domain—even if you’ve never used them. A CAA record (0 issue "ca-domain") doesn’t exist, so nothing stops a rogue admin, an attacker who gains control of a DNS editor, or a compromised third-party tool from obtaining a valid cert. You won’t know until it’s used in a phishing campaign or man-in-the-middle attack.
How to Fix It
Publish a CAA record in your DNS that whitelists only the CAs you actually use. A record like 0 issue "letsencrypt.org" restricts issuance to Let’s Encrypt; add multiple lines for additional CAs. This makes unauthorized issuance visible—CA transparency logs will still show the rejection. For a full explanation of how these records work and how to set them up, refer to CAA Records.
Self-Signed Certificates: The Trust That Isn’t There
The Problem
A self-signed certificate triggers a browser warning like NET::ERR_CERT_AUTHORITY_INVALID. Internal tools, dashboards, or test servers often use them for convenience. But every time an employee clicks “Proceed anyway,” they train themselves to ignore certificate errors—a behavior that real attackers exploit in phishing and network interception attacks. Self-signed certs also break API integrations that require proper validation.
How to Fix It
Replace every self-signed certificate with one issued by an internal CA (for private services) or a public CA (for anything internet-facing). If you need a quick internal fix, set up a private PKI that pushes its root cert to all company devices, so trust is automatic and warnings disappear. Our deep dive on Self-Signed TLS Certificate clarifies when they’re ever acceptable and when they’re outright dangerous.
Build a Monitoring Habit That Actually Works
Certificate hygiene doesn’t stick because someone once wrote a policy. It sticks when the right checks run automatically. Below is a concrete sequence that moves you from reactive panic to proactive safety.
The Bottom Line
An expired certificate isn’t a minor oops; it’s a revenue-stopping, trust-erasing event. But the solutions are well-understood. Automation handles expiry. CAA records lock issuance. Wildcard discipline contains breaches. And you stop teaching your team to ignore warnings by removing self-signed certs.
These controls live in your DNS and your certificate inventory—both of which are silent until something fails. A scan of your domain reveals which of these risks are already present, and how close you are to the next Monday morning outage. Get the full picture today: run a TechSpy scan and stop waiting for the warning page.