Monitoring
The silent SSL expiry: how an expired certificate can take down checkout without a single error page
Richard K. · October 29, 2026 · 9 min read
A customer adds three items to their cart, clicks through to checkout, and their browser stops them cold: "Your connection is not private." No error page from your store. No 500 status code. No alert in your admin dashboard. Just a red warning screen that tells the customer, in no uncertain terms, that something about your site cannot be trusted with their credit card number. Most of them will not click through. They will close the tab and buy from someone else.
Why SSL expiry is invisible until it isn't
SSL certificates are small files with an expiration date, usually 90 days to a year out depending on who issued them. When a certificate expires, the padlock in the browser's address bar disappears and is replaced with a warning. This is not a server crash. Your product pages might load fine. Your admin panel works normally. Your order-flow dashboards show nothing unusual because, technically, nothing on your server has changed. The only thing that changed is a date on a certificate, and browsers treat that as a trust failure serious enough to block the page outright.
This is what makes SSL certificate expiration different from most outages. A broken checkout button or a 500 error is loud. An HTTPS checkout error is quiet. It shows up to customers, not to you, unless you are specifically watching for it.
The problem is worse on custom domains and third-party checkout integrations than on a platform's default setup. Shopify, WooCommerce, and BigCommerce all handle SSL automatically for their own domains and hosted checkout pages. But the moment you add a custom domain, a subdomain for a headless storefront, a third-party payment page, or a checkout extension hosted elsewhere, you introduce a certificate that may not be covered by that automatic renewal. Someone has to own it. Often, nobody does.
Where certificates quietly go stale
Most SSL certificates today are issued through automated systems (Let's Encrypt is the most common) and renew every 60 to 90 days without anyone touching them. That automation is reliable almost all the time, which is exactly why failures catch people off guard. A renewal depends on a few things working in sequence: DNS records pointing correctly, a renewal service having the right permissions, and nothing interrupting the process. Any one of these can break quietly.
A few scenarios we see repeatedly:
A store moves to a new DNS provider or changes nameservers, and the automated renewal process loses the ability to verify domain ownership. The old certificate keeps working until it expires, then nothing replaces it. This is closely related to the kind of DNS propagation delay that causes other silent outages after domain changes.
A store uses a third-party checkout page, a custom payment gateway integration, or a headless frontend on its own subdomain (checkout.yourstore.com, pay.yourstore.com). These often sit outside the platform's managed SSL and are renewed by a different vendor or a different team entirely. When that vendor's certificate lapses, your main store looks fine. Checkout does not.
A store switches hosting providers, CDNs, or app platforms mid-renewal-cycle, and the new setup doesn't carry over the certificate configuration. The gap might not show up until the old certificate's expiration date arrives, which could be weeks after the switch.
Someone manually installed a certificate years ago (common on older WooCommerce or BigCommerce setups with custom SSL) and the renewal was never automated at all. It simply has a hard expiration date sitting on someone's calendar, if it's on a calendar at all.
What customers actually see, and what it costs you
When a certificate expires, browsers don't quietly downgrade the connection. Chrome, Safari, and Firefox show a full-page interstitial warning with language like "Your connection is not private" or "This connection is not secure," and they make it deliberately hard to proceed. Most browsers bury the "continue anyway" option behind an extra click or two specifically to discourage people from ignoring it.
For a checkout page, this is close to the worst possible failure mode. Customers who were already in a buying mindset, cards in hand, suddenly see the digital equivalent of a storefront with crime scene tape across the door. Some will assume the store has been hacked. Most won't wait around to find out. Unlike a slow page or a confusing coupon field, a browser security warning doesn't invite troubleshooting. It invites leaving.
The revenue impact compounds because the failure is binary and total for everyone who hits it. Every visitor who reaches the affected domain during the expiry window sees the same warning, and conversion effectively drops to whatever small fraction of people click through browser warnings on a purchase page. If the certificate lapses on a Friday night and nobody notices until Monday, that's an entire weekend of checkout traffic lost quietly, with no support tickets (customers rarely email a store to report a security warning; they just leave) and no obvious spike in your analytics beyond a conversion rate that looks oddly flat.
An expired certificate doesn't break your store. It breaks your customers' trust in your store, which is a more expensive thing to lose.
A monitoring routine that catches it early
The fix for SSL expiry is not complicated, but it requires checking the right things on a schedule, because the failure gives no other warning. A workable routine:
List every public-facing domain and subdomain connected to your store. This includes your primary domain, any legacy domains that redirect to it, checkout or payment subdomains, headless storefront domains, and any region- or language-specific domains if you run a multilingual setup. If you're not sure this list is complete, that's worth fixing before anything else.
Check the expiration date on each certificate, not just whether the site currently loads. A certificate can be valid today and twelve days from expiring, which tells you nothing if you only check "is HTTPS working right now." You want a check that reads the actual expiration date and flags anything inside a 30-day window, giving you time to investigate and renew.
Run these checks independently of your own admin or analytics tools. Since your platform dashboard won't show a certificate problem on a third-party domain, the check needs to originate from outside your infrastructure, the way an external monitor would see your site. This is the same principle behind good uptime monitoring generally: you want visibility from the customer's vantage point, not just your own.
Pay particular attention after any domain, DNS, hosting, or checkout-integration change. These transitions are when automated renewal most often breaks, and the breakage won't surface until the old certificate's expiration date, which can be weeks later and easy to forget about by then.
This is part of what store security monitoring should cover day to day. Cassian™ checks SSL certificate status and expiration across your store's domains as part of its continuous monitoring, alongside uptime, broken links, and the other health signals that feed into the Cassian Score™. The goal isn't to replace your renewal process, it's to catch the moment that process quietly fails, before a customer does it for you with a screenshot of a warning page.
Frequently asked questions
- How do I know if my SSL certificate is about to expire?
- The most reliable way is to check the certificate's expiration date directly, either through your browser's padlock icon details, a free SSL checker tool, or an automated monitoring service that tracks it continuously. Don't rely on the site loading normally as a sign of health, since a certificate can be valid one day and expired the next with no other warning. Setting an alert for 30 days before expiration gives enough lead time to investigate and renew, especially on domains managed outside your main ecommerce platform.
- Can an SSL issue affect just my checkout page and not the rest of my store?
- Yes, this happens often when checkout runs on a separate domain or subdomain from your main storefront, such as a custom payment gateway page or a headless checkout integration. Each domain or subdomain typically has its own certificate, so one can expire while others remain valid. A Shopify SSL issue of this kind is common when a custom domain is connected but its certificate renewal isn't fully managed by Shopify's automated system, leaving the main store fine while checkout shows a browser security warning.
- Will customers tell me if they see a security warning at checkout?
- Almost never, because most customers assume a security warning means something is actively wrong or suspicious, and their instinct is to leave rather than report it. You're far more likely to notice an unexplained drop in conversion rate or order volume than to receive a support ticket describing the warning. This is why independent monitoring that checks certificate expiration from outside your own systems matters: it catches the problem before customer behavior forces you to notice it indirectly.
The quiet fix for a quiet problem
SSL expiry is one of the few store failures that is entirely preventable with a calendar and a checklist, yet it keeps catching stores off guard because it hides in the gap between "my site loads fine for me" and "a customer's browser just blocked them from buying anything." The underlying issue, the SSL certificate that expired overnight, tends to surface at the worst possible moment: a weekend, a holiday sale, right after a migration nobody double-checked.
The fix isn't more vigilance from you personally. It's making sure something is checking certificate expiration on every domain your checkout touches, on a schedule, from outside your own dashboards, so the warning reaches you before it reaches your customers.