SSL Certificate Name Mismatch: What It Means and How to Fix It
A certificate name mismatch means the certificate presented for a connection does not list the hostname you opened, even if the certificate itself is otherwise valid.
How it works
Modern clients match hostnames against Subject Alternative Names (SANs). The subject name alone is not a substitute for the required DNS name coverage.
Hostname matching is exact enough to surprise people. A certificate containing example.com does not automatically cover www.example.com or api.example.com. A certificate containing *.example.com can cover api.example.com and www.example.com, but it does not cover the apex example.com or a deeper name such as v1.api.example.com.
SANs are the names clients use for matching. A certificate can have valid dates, a trusted issuer, and a complete chain while still failing because the requested host is absent from its SAN list. That is why certificate valid and hostname match no can coexist without contradiction.
Shared infrastructure is a frequent source. A CDN, reverse proxy, or load balancer uses SNI to select a certificate for the hostname supplied during TLS setup. If the listener has no matching certificate, an old default certificate can be served. Testing the IP address alone is not enough because a shared address can host many domains.
Check the exact public hostname and port, then compare presented SANs, issuer, dates, and fingerprint with the intended deployment. Review the CDN edge, proxy virtual-host mapping, and load-balancer certificate attachment. If DNS still points some users to an old endpoint, check that route before replacing the certificate again.
The SSL checker reports the certificate observed from the service environment. It does not prove every geographic edge, browser, or authenticated route receives the same certificate. Use it to isolate the public endpoint, then correct the server or proxy configuration rather than asking users to ignore a name warning.
Common mismatch patterns
www.example.com and example.com are different names; each must be covered unless one redirects before TLS is negotiated, which it cannot on the same HTTPS endpoint. A wildcard such as *.example.com can cover one label like app.example.com, but not example.com or deep.api.example.com.
A CDN, load balancer, reverse proxy, or shared IP can present the wrong certificate when SNI is missing or mapped incorrectly. The same address may host many names, so test the intended hostname rather than judging the IP's default certificate.
Fix the deployment, not the warning
Inspect the presented certificate's SAN list, issuer, fingerprint, and expiry for the exact hostname and port. Compare it with the certificate intended for that route. Then check CDN edge configuration, load-balancer listeners, proxy host rules, and SNI settings.
Do not advise users to bypass a browser warning. Renewing a certificate does not fix a mismatch if the wrong endpoint still serves it. DNS can also lead users to an old edge, so verify the hostname's public resolution and deployment state after the correction.
Practical guidance
- Test the exact hostname users enter, including www or a subdomain.
- Check SAN coverage before replacing a certificate.
- Review SNI and proxy mapping on shared endpoints.
Common question
Can a certificate be valid and still mismatch? Yes. Its dates and chain can be valid while its names do not cover the requested host.