TLS hostname mismatch — certificate doesn't cover the name
'SSL: certificate subject does not match hostname' in clients
Focused incident mode — strips away everything but this runbook.
Symptoms
- 'SSL: certificate subject does not match hostname' in clients
- Browser reports NET::ERR_CERT_COMMON_NAME_INVALID
- curl fails with 'certificate name mismatch' despite a valid chain
Evidence to grab
Collect these artifacts before you change anything — they prove (or rule out) each cause.
Serving certificate identity
echo | openssl s_client -connect <HOST>:443 -servername <HOST> 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName
Diagnostic flow
Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.
Guided decision tree is ready.
Steps with commands, expected output, and pass/fail branches.
Ranked root causes
Evidence checklist
- Public host serves the default VIP certificate
- In a Kubernetes/ingress setup, the Ingress TLS block is missing
Confirm before fixing
kubectl get ingress -A -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.tls}{"\n"}{end}'Check which Ingresses declare TLS secrets
Expected: No .spec.tls for the failing host
Fix
kubectl edit ingress <INGRESS> -n <NAMESPACE>Add the host + secretName to spec.tls
Resolution runbook
Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.
echo | openssl s_client -connect <HOST>:443 -servername <HOST> 2>/dev/null | openssl x509 -noout -ext subjectAltNameConfirm exactly which names are covered
curl -sv https://<HOST>/ 2>&1 | head -20Reproduce; note the error text
Prevention
- Use wildcard or multi-SAN certs for shared/ingress domains.
- Automate SAN generation from the Ingress host list.
- Add a periodic curl-based check across your host matrix.
Related runbooks
Same stack, same failure family — worth a skim.
Clients get 'certificate has expired' or verification error
Browser shows certificate warning for a vhost -- certificate CN doesn't match the hostname
Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.