The company had a wildcard certificate for *.example.com, covering every customer subdomain the product created — acme.example.com, widgetco.example.com, and so on, dynamically provisioned per customer. It had worked reliably for well over a year, which is exactly the kind of track record that quietly turns an assumption into an unquestioned fact.
What changed
A new feature introduced a further layer of per-environment subdomains for enterprise customers who wanted staging and production environments separated — staging.acme.example.com alongside acme.example.com. The engineer building it assumed, reasonably enough given how the wildcard had always "just worked," that this new deeper subdomain would be covered the same way. It deployed cleanly in every internal test against a handful of dummy accounts and shipped.
Where it actually broke
The first real enterprise customer to use the new staging-subdomain feature hit an immediate certificate error — and this time, unlike some of the more obscure failures elsewhere in this series, the browser's own error message was actually specific enough to point at the real problem: the certificate's SAN list covered *.example.com but not *.acme.example.com. A wildcard covers exactly one level of subdomain depth, not an arbitrary depth — something the engineer had known abstractly, in the way you know a fact you've read once, without it being load-bearing in an actual decision until this exact moment.
The fix, and the harder conversation
The immediate fix was straightforward: the new staging-subdomain pattern needed its own certificate strategy, since a second-level wildcard certificate for something like *.acme.example.com would need to be issued per-customer, or the product's subdomain structure needed rethinking to stay within the single wildcard's actual coverage. The team chose the latter — restructuring the staging distinction to use a path or a first-level subdomain naming convention instead (acme-staging.example.com) rather than nesting deeper, specifically so the existing wildcard kept covering everything without per-customer certificate provisioning.
Why this one is worth remembering
The genuinely useful takeaway wasn't "read the documentation more carefully" in the abstract — it's that a system working correctly for a long time on a narrow range of inputs (subdomains one level deep, in this case) builds a kind of confidence that doesn't actually generalize, and the moment that gets tested is often the first time a genuinely new pattern of usage shows up, not the hundredth. See our wildcard vs multi-domain guide for the exact coverage rules.
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: Wildcard vs Multi-Domain Certificates
Loading comments…