highFoundationSymptom-first#tls#hostname#san#mismatch

TLS hostname mismatch — certificate doesn't cover the name

'SSL: certificate subject does not match hostname' in clients

Likely source:configurationconnectivity

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}'
READ

Check which Ingresses declare TLS secrets

Expected: No .spec.tls for the failing host

Fix

kubectl edit ingress <INGRESS> -n <NAMESPACE>
CHANGE

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.

1
echo | openssl s_client -connect <HOST>:443 -servername <HOST> 2>/dev/null | openssl x509 -noout -ext subjectAltName
READ

Confirm exactly which names are covered

2
curl -sv https://<HOST>/ 2>&1 | head -20
READ

Reproduce; 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.

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.