Certificates days from expiry
A TLS certificate can look like a small technical detail until it expires. Then a customer sees a browser warning instead of your website, an integration rejects the connection, or an employee cannot reach a critical portal. The result is both an availability problem and a trust problem: the service may be healthy behind the scenes, but users cannot establish a trusted connection to it.
Received a PagerDuty ON A SUNDAY. Expired TLS cert took down every domain we have (Around 33 domains). Our monitors were supposed to catch it.
What our scan found
In our monthly refresh generated on 2026-10-07, certificates approaching expiry appeared at 0.4% (n=4) among a population of US B2B SaaS companies with 5-50 employees, N = 1105. The percentage is small, but the consequence for any affected domain can be immediate. Certificate expiry does not gradually make a site less secure. Once clients no longer accept the certificate, normal traffic can fail outright.
Methodology: OrangeStealth collected these observations using passive, public-data-only checks. The sample covered US B2B SaaS companies with 5-50 employees, N = 1105. Results are k-anonymised, and no company is named. Public HTTP and DNS observations identify externally visible conditions, not evidence of abuse, compromise, or any particular backend practice.
Why renewal failures become outages
A valid certificate helps a browser or application confirm that it reached the expected domain and establish an encrypted connection. Certificates have expiration dates, so renewal has to happen before the current certificate becomes invalid. Automation usually handles that work, but automation is not the same as assurance.
Renewal can fail because a validation record is missing, a challenge path no longer reaches the right service, an account or integration has changed, or the new certificate was issued but never installed on every endpoint. A load balancer, forgotten subdomain, regional deployment, or third-party platform can continue presenting an old certificate even when the main website looks fine.
The dangerous assumption is that successful issuance means successful renewal. The real outcome depends on what each public endpoint is serving. Monitoring should therefore check the certificate that customers actually receive, not only the internal job that requested it.
I had a need recently to do a full inspection of all SSL certs and DNS records for every domain loaded by a web page.
A hypothetical failure path
Consider a hypothetical software company whose main website and customer login use different hosting paths. The main certificate renews correctly, so the marketing site remains available. The login endpoint keeps serving the older certificate because its deployment step failed. Internal dashboards show that a renewal job completed, but customers receive a certificate warning when they try to sign in.
Nothing in that observation proves an attacker was involved. It does show how a narrow configuration failure can interrupt access and create uncertainty at exactly the point where a customer expects reassurance. Support teams may initially investigate passwords, application health, or network connectivity while the actual problem sits at the TLS boundary.
What to actually do about it
- Inventory public TLS endpoints. Include customer portals, APIs, authentication pages, file services, regional hosts, redirects, and externally managed platforms. A certificate process cannot protect an endpoint nobody remembers exists.
- Monitor what each endpoint presents. Check the live certificate, hostname coverage, chain validity, and expiration state from outside your network. Do not rely solely on renewal-job success messages.
- Alert early enough for human recovery. Renewal automation should leave room to diagnose validation, deployment, and vendor problems before customers encounter them. Route alerts to a monitored destination with a clear owner and escalation path.
- Test the full renewal path. Confirm that issuance, deployment, service reloads, edge distribution, and external presentation all complete. A renewed certificate sitting in storage does not protect a live service.
- Prepare a manual recovery procedure. Document who can renew and deploy a certificate, which systems are involved, how external validation works, and how to confirm recovery without exposing private keys.
A free public check at https://orangestealth.com/check can help identify what an internet-facing domain currently presents. It is distinct from an External Security Posture Assessment, which reviews a broader set of passive, external signals and helps prioritize the findings.
Start with the endpoints tied to customer access and revenue, then verify that each one has an owner, an external expiry alert, and a tested recovery path. The certificate itself may be routine. Making sure its failure cannot surprise the business is the real work.