TLS certificate does not validate
The certificate served for the subdomain does not validate (for example a timeout or a 404).
Why it matters
The certificate served for the subdomain does not validate (for example a timeout or a 404). Every visitor is met with a full-page browser security warning and most will not click through it, so the site is effectively offline — and API clients, webhooks and mobile apps refuse the connection outright rather than warning a human who might proceed. This is one of the most common causes of a sudden, total outage, and it will not resolve on its own.
How ShipReady detects it
TLS configuration checks. The only check that inspects the transport itself rather than an HTTP response, so it opens its own TLS connections instead of using the shared PageContext. Both probes are passive: a TLS handshake exchanges no application data, sends no request, and changes nothing on the server. Certificate expiry is the highest-value item here — an expired certificate takes a site completely offline for every visitor, and it is entirely preventable with notice.
Detection is deterministic. ShipReady reports this only when it observes the condition directly, and prefers to miss a real problem over inventing one. Rule version 1.0.0.
How to fix it
This is the prompt ShipReady puts in your report — written to be pasted straight into Cursor, Claude Code, or whichever assistant built the app.
The TLS certificate served for the subdomain does not validate (for example a timeout or a 404), so every browser shows a full-page security warning before your site loads and most visitors never click through — the site is effectively offline, and API clients and webhooks refuse the connection outright. Fix depends on the cause: for an expired certificate, renew it (Let's Encrypt via certbot/acme.sh, or your host's managed certificates) and add an expiry alert; for a self-signed or untrusted certificate, replace it with one from a public certificate authority — a self-signed cert is fine for local development but never for a site real users reach; for a hostname mismatch, issue the certificate for the exact hostname you serve (include both apex and www, or use a wildcard) rather than reusing another host's cert. Most managed hosts (Vercel, Netlify, Cloudflare, Render) provision and renew a valid certificate automatically once the domain's DNS points at them, so if you are managing certificates by hand consider moving this to the platform.
Frequently asked questions
- What does "TLS certificate does not validate" mean?
- The certificate served for the subdomain does not validate (for example a timeout or a 404).
- How serious is it?
- ShipReady rates this high. Fix before launch. A real weakness that an attacker can act on.
- How do I fix it?
- Paste the fix prompt on this page into Cursor, Claude Code or your AI editor. It is the same prompt ShipReady puts in your report.
- Can I check my own site?
- Yes — ShipReady scans up to ten pages of any public site for free and reports this alongside every other check. The free report lists every issue it finds and shows full evidence and a fix prompt for the critical and high-severity ones; medium and low findings are counted and unlock on Pro.
Related checks
Run this check on your site
ShipReady checks this and 193 other things across up to ten pages of your site, with an AI-ready fix for each. Free, no signup.