The support ticket was oddly specific: a handful of customers reported the checkout page showing a certificate error, but only "sometimes," and never when anyone on the engineering team tried to reproduce it from the office. Every internal test — from the office WiFi, from a VPN, from a personal laptop at home — loaded the checkout page correctly, valid padlock, no warning.
The actual pattern took a day and a half to notice: every affected report came from someone on a mobile carrier's network specifically, never from a home or office WiFi connection. That's an unusual axis for an SSL problem to split on — TLS itself doesn't care what network layer it's running over.
Where the investigation actually turned
The breakthrough came from asking an affected customer to run a basic connectivity check from their phone while on cellular data, comparing the IP address their phone resolved for the checkout domain against the IP address the office resolved. They were different. The company's DNS had two A records for load distribution, pointing at two different servers behind the same load balancer setup — and only one of the two servers had the checkout domain's certificate correctly configured in its virtual host block. The other was silently falling through to a default server block serving a completely different (and expired) certificate.
Office WiFi happened to resolve consistently to the correctly-configured server, purely by coincidence of DNS caching and which resolver was in the path. Mobile carriers, with their own DNS infrastructure and different caching behavior, were hitting both servers roughly evenly — surfacing the misconfigured one at a rate high enough to generate tickets, but low enough to make it maddening to reproduce on demand.
The actual fix
The second server's nginx configuration was missing the correct server_name directive tying it to the checkout domain's certificate block — a copy-paste artifact from when the second server had been provisioned as a near-duplicate of the first, with one line never updated. Once corrected, both servers served the correct certificate for every request regardless of which one handled it.
What made this one worth writing down
The genuinely useful lesson wasn't the fix itself — it was how load-balanced, multi-server setups can hide a per-server certificate misconfiguration behind statistics. If only one of several backend servers is affected, and traffic is distributed across them, the error rate you see depends entirely on which server a given request happens to land on — which is exactly the kind of thing that looks like network-specific flakiness until you think to check server-by-server instead of network-by-network. See our guide to SNI misconfigurations for the underlying mechanism.
This case study is written to illustrate a genuine, common troubleshooting pattern. It is not a direct quotation or a verified account tied to a specific, identifiable individual or company. For the underlying technical reference, see: Fixing Multi-Tenant SNI Issues
Loading comments…