5 SSL certificate mistakes that could take down your website

Avoid these common SSL certificate mistakes that cause website outages, security warnings, and lost customers. Learn how to manage certificates the right way.

SSL certificates seem simple enough: install one, and your site is secure. But in practice, certificate management is full of pitfalls that catch even experienced IT teams off guard.

Here are five common SSL certificate mistakes—and how to avoid them.

Mistake #1: Letting certificates expire

This is the big one. An expired SSL certificate triggers immediate, alarming browser warnings that drive visitors away. Your site might as well be offline.

The frustrating part? Certificate expiration is completely predictable. You know exactly when it will happen. Yet organizations of all sizes—from small businesses to tech giants like Microsoft and Spotify—have suffered embarrassing outages because someone forgot to renew a certificate.

Why it happens:

  • Renewal emails go to spam or outdated addresses
  • The person who set up the certificate has left the company
  • Multiple certificates across different domains and servers make tracking difficult
  • Manual calendar reminders get missed

How to avoid it:

Set up automated monitoring that tracks all your certificates and alerts you well in advance of expiration. Don't rely on emails from certificate authorities—they often don't arrive, or arrive too late. Use multiple notification channels (email, Slack, SMS) to ensure someone sees the alert.

This is exactly what CheckYourSSL does. We monitor all your certificates and alert you 30, 14, and 7 days before expiration—or on whatever schedule you prefer. Join the beta and stop worrying about surprise expirations.

Mistake #2: Forgetting about subdomains

You've got a certificate for example.com. Great. But what about www.example.com? Or api.example.com? Or staging.example.com?

Each subdomain may need its own certificate coverage. A standard single-domain certificate typically covers only the exact domain specified (though many include the www subdomain as a bonus). If you've set up a new subdomain and forgotten to include it in your certificate coverage, visitors to that subdomain will see security warnings.

Why it happens:

  • Developers spin up new subdomains for projects without thinking about SSL
  • Wildcard certificates aren't configured correctly
  • Testing environments are assumed to not need certificates (until they're accidentally exposed to users)

How to avoid it:

Consider wildcard certificates if you frequently create new subdomains. Maintain an inventory of all your domains and subdomains, and review it regularly. Make SSL certificate coverage part of your checklist when deploying new services.

Mistake #3: Mixed content warnings

You've installed your SSL certificate, your site loads over HTTPS, and everything seems fine. Then you notice the padlock icon is missing, replaced by an information icon or a "Not Secure" warning.

The culprit: mixed content. Your page is loaded over HTTPS, but some resources on that page—images, scripts, stylesheets, fonts—are being loaded over HTTP. This undermines the security of your HTTPS connection and triggers browser warnings.

Why it happens:

  • Hard-coded HTTP URLs in your codebase
  • Content management systems storing absolute URLs from before the HTTPS migration
  • Third-party widgets or scripts that don't support HTTPS
  • User-generated content with embedded images from HTTP sources

How to avoid it:

Use relative URLs or protocol-relative URLs where possible. Run a site audit to find mixed content issues (browser developer tools can help). Implement Content Security Policy headers to block mixed content. Update your CMS to store HTTPS URLs. Choose third-party services that support HTTPS.

Mistake #4: Incomplete certificate chains

An SSL certificate doesn't work alone. It's part of a chain of trust that leads back to a root certificate authority. Your server needs to provide not just your certificate but also any intermediate certificates that link your certificate to the root.

If intermediate certificates are missing, some browsers and devices won't be able to verify your certificate. You might see no problems on your desktop browser but get errors on certain mobile devices or older systems.

Why it happens:

  • The person installing the certificate didn't know about intermediate certificates
  • Hosting provider configurations vary, and some don't make the process clear
  • Certificate renewals sometimes change the required intermediate certificates

How to avoid it:

Always check your SSL installation with online testing tools that verify the complete certificate chain. Follow your certificate authority's installation instructions carefully—they'll tell you which intermediate certificates are needed. Test your site on multiple browsers and devices after installing or renewing a certificate.

Mistake #5: Not monitoring certificate health

Installing a certificate isn't a one-time task. Certificates can become invalid for reasons beyond expiration:

  • The certificate authority might revoke your certificate (rare, but it happens)
  • Your server configuration might change, breaking the SSL setup
  • DNS changes could affect certificate validation
  • A certificate might be replaced incorrectly during a server migration

If you're only checking your certificates manually—or worse, only when someone complains—you're leaving yourself vulnerable to extended outages.

Why it happens:

  • Organizations focus on initial installation but not ongoing maintenance
  • Manual checks are infrequent and inconsistent
  • Problems can occur between scheduled checks

How to avoid it:

Implement continuous monitoring that regularly checks not just expiration dates but also certificate validity, chain completeness, and configuration correctness. Get alerts when anything changes, not just when expiration approaches.

Bonus mistake: Poor certificate documentation

Who bought this certificate? Where is it installed? When does it expire? Who's responsible for renewal?

If you can't answer these questions quickly for every certificate your organization uses, you're at risk. Staff turnover, organizational changes, and simple forgetfulness can leave certificates orphaned—still protecting critical services but with no clear owner.

How to avoid it:

Maintain a centralized inventory of all certificates. Document the domains covered, installation locations, expiration dates, and responsible parties. Update this documentation whenever certificates are added, removed, or changed.

Prevention beats recovery

All of these mistakes share a common theme: they're preventable with proper monitoring and documentation. The time to catch these problems is before they affect your users—not after.

Automated monitoring transforms certificate management from a crisis-prone chore into a routine, manageable task. Instead of scrambling to fix problems, you're calmly addressing them before they become emergencies.