Introduction

A certificate common name invalid error on a subdomain means the client reached a server that presented a certificate for a different hostname. The mismatch may come from the wrong certificate, the wrong virtual host, broken SNI routing, or a proxy layer serving an old cert while the origin looks fine. The quickest fix is to confirm exactly which certificate the subdomain serves at every layer in the request path.

Symptoms

  • Browsers warn that the certificate is invalid for a subdomain such as api, blog, or shop
  • The apex domain works, but the subdomain fails HTTPS validation
  • The issue started after adding a new subdomain, proxy, or certificate renewal
  • SSL checkers show a certificate for a different hostname than the requested subdomain
  • One region or edge location fails while another appears correct

Common Causes

  • The deployed certificate does not include the affected subdomain in its SAN list
  • The server or proxy maps the subdomain to the wrong certificate or virtual host
  • SNI is misconfigured, so the default certificate is served instead of the matching one
  • A CDN or load balancer still presents an older certificate after renewal
  • DNS points the subdomain to a different endpoint than the one you intended to secure

Step-by-Step Fix

  1. Test the exact failing subdomain with an SSL checker and record which certificate chain is actually being served.
  2. Verify the active certificate includes the subdomain in its SAN entries, not just the apex or wildcard assumptions.
  3. Check DNS resolution so the subdomain points to the endpoint you expect to be serving the correct certificate.
  4. Review server, proxy, or load-balancer SNI mapping to confirm the hostname selects the intended TLS configuration.
  5. Compare origin and edge certificates separately if a CDN or reverse proxy sits in front of the application.
  6. Confirm the renewed or replacement certificate was deployed everywhere traffic can land, not just on one node.
  7. Purge or reload TLS configuration after correcting certificate mappings so stale listeners do not continue serving the old cert.
  8. Retest from more than one network path if the site uses multiple regions, edges, or failover endpoints.
  9. Document subdomain certificate ownership so future hostname additions do not go live before TLS coverage is complete.