Why a hostname mismatch happens
When a client connects to api.example.com, it compares that requested name with the certificate’s Subject Alternative Name list. The certificate can be issued by a reputable authority and remain within its validity dates, but the connection still fails if the requested name is not covered.
Common misconception: the Common Name is not a reliable replacement for modern SAN validation. Check the SAN list and the exact hostname being requested.
Typical causes
- A new subdomain was added without reissuing the certificate.
- A reverse proxy or CDN serves a default certificate for the wrong site.
- DNS was moved but the old service still answers on the address.
- A wildcard certificate is being used outside the level it covers.
- One node in a load-balanced group has stale configuration.
How to troubleshoot
- Record the exact hostname, including whether it uses a regional or service-specific subdomain.
- Inspect the certificate actually returned by that hostname with SNI enabled.
- Compare the SAN entries with the requested name and wildcard rules.
- Check proxy, load-balancer, and DNS configuration for a default-site response.
- Reissue and deploy the certificate, then test each public path.
Certificate Inspector reports the SAN evidence returned by the tested endpoint. It does not prove that every client path, private hostname, or alternate listener uses the same certificate.
Last reviewed: September 2026. Always confirm production changes with the service owner.