If you’ve recently encountered the dreaded net::ERR_CERT_COMMON_NAME_INVALID error in Google Chrome while using a valid, up-to-date SAN (Subject Alternative Name) certificate, you’re not alone. This perplexing issue sparked waves of confusion across the web development and sysadmin communities. At first glance, it seemed like a failure of HTTPS itself — a valid certificate actively being rejected by the browser. What gives?
This article dives into the core of the problem, explains why this error became so widespread seemingly overnight, and outlines the workaround involving SAN ordering and Host headers that resolved the issue. By understanding the root cause, professionals can ensure HTTPS trust remains intact in their configurations.
TL;DR
Chrome began strictly validating SAN certificates against the HTTP Host header, rather than relying only on the SAN list in any order. If a mismatch between the Host header and the first SAN field occurred — or if the Host header didn’t align with any SAN at all — Chrome threw the net::ERR_CERT_COMMON_NAME_INVALID error. The fix involved aligning the Host header precisely with the SAN entries — preferably the first SAN — and ensuring SAN ordering reflected request patterns. This behavior made some previously acceptable certificate configurations invalid overnight, but the changes ensure tighter HTTPS security enforcement.
What Is the ERR_CERT_COMMON_NAME_INVALID Error?
The net::ERR_CERT_COMMON_NAME_INVALID error appears when there’s a mismatch between the domain a user is trying to access via HTTPS and the names listed on the server’s SSL certificate. Essentially, the certificate does not appear to be valid for the domain from the browser’s point of view.
Traditionally, as long as the domain was included somewhere in the certificate — either in the Common Name (CN) or in the Subject Alternative Names (SANs) — most browsers would accept it as valid. Chrome, however, upped its security game.
With updates starting around Chrome version 58, Google dropped support for CN-only validation and began exclusively checking against SANs. But the real needle-mover came with additional enforcement in newer versions of Chrome — which started inspecting not just the content of the SAN list but how it related to the requested domain and the host header.
Understanding SAN Certificates
A SAN certificate allows a single SSL certificate to protect multiple domain names. It’s commonly used for:
- Multi-domain SSL configurations
- Load-balanced services with different domain names
- Multi-tenant systems
Here’s what a SAN certificate might include:
CN = mainsite.com
SAN = [mainsite.com, www.mainsite.com, api.mainsite.com, login.mainsite.com]
In theory, as long as the domain you’re accessing is listed, it should be okay. But that’s not how Chrome saw things after its update.
What Changed in Chrome?
Chrome started enforcing a stricter match between the domain users visit, the certificate’s SANs, and most significantly — the Host header of HTTP(S) requests. If the Host header value didn’t match a SAN — or worse, if it matched one further down in the list — Chrome would consider the certificate invalid.
Additionally, it began giving preference to the first SAN in the list when making an HTTPS trust validation decision. So, even if your domain was present somewhere in the list, it may still fail if the primary SAN and Host header weren’t aligned.
This new sensitivity was likely introduced to improve security, especially in multi-tenant or shared-hosting environments where malicious redirection could be more prevalent. But it had the side effect of invalidating previously safe certificate configurations.
Real-World Scenario: When SAN Ordering Breaks Trust
Consider a scenario where your SAN certificate includes:
SAN = [api.example.com, www.example.com, example.com]
If a user visits https://example.com, but the Host header sent by your application still uses api.example.com, Chrome may reject the certificate. Why? Because Chrome checks whether the Host header value matches the name of the website you’re visiting, then compares this against the certificate’s SANs. If there’s any discrepancy — or if the order is off — it doesn’t pass validation.
Why the SAN Order Matters
Suddenly, the ordering of SAN fields became important. A browser like Chrome looks at the first SAN as the primary “intended” domain. If this domain doesn’t match what the client expects or what the Host header presents, the certificate may not be trusted.
This was especially problematic for services using shared or wildcard certificates across subdomains — where the end-user might request one hostname while the certificate’s first SAN is another.
In the past, this mismatch might have gone unnoticed or been accepted by most browsers. Not anymore.
The Role of the Host Header
The Host header in HTTP requests indicates which domain the request is targeting, especially important in shared hosting environments. Chrome began tying this field directly to SSL validation, using it to infer whether the intended domain matches the certificate.
That means if your application logic or proxy configuration sends an incorrect Host header — even if the certificate supports the target domain — you’re going to see a net::ERR_CERT_COMMON_NAME_INVALID error.
Steps to Fix It: SAN Ordering & Host Header Integrity
After diagnosing this issue, here’s how many systems administrators and developers restored trust and resolved the error:
- Check the certificate’s SAN entries. Ensure the primary domain that users will access is listed first in the SAN list.
- Validate Host header is correctly set. Whether you’re using a load balancer, API gateway, or reverse proxy, ensure the correct Host is passed along.
- Use server-side TLS SNI (Server Name Indication). This ensures the server selects the right certificate when multiple are presented.
- Regenerate the certificate with correct SAN order. Tools like OpenSSL let you specify SAN order explicitly after Chrome’s change.
Here’s a basic way to regenerate a SAN certificate where order matters:
openssl req -new -nodes -out request.csr -keyout key.pem -config san.cnf
Inside san.cnf, control the SAN order:
subjectAltName = DNS:example.com, DNS:www.example.com, DNS:api.example.com
This ensures example.com (the root domain) is listed first, aligning with user expectations and browser checks.
Conclusion
What started as a minor browser update turned into a fully-fledged TLS validation headache for some. Chrome’s stricter enforcement of SAN fields and Host header checking brought an end to ambiguities in SSL trust, but it also forced many to re-examine their certificate provisioning processes.
By correcting SAN ordering and ensuring Host headers reflect requested domains, developers and IT teams managed to restore seamless HTTPS coverage. While it introduced temporary pain, the long-term benefit is a more secure and predictable web for users everywhere.
Keep these lessons in your toolkit when you next deploy a new certificate — especially on multi-domain setups — and Chrome (and your users) will thank you.