ERR_CERT_COMMON_NAME_INVALID hostname errors

Hostname mismatch errors appear when CN/SAN do not cover the URL; renew with correct names and confirm expiry on the cert users actually receive.

Renaming products without updating certificates leaves sites reachable only by accidental partial matches. Chromium reports common name invalid when the served name is absent from SAN.

Expiry and mismatch can coexist after cutover: the old hostname still DNS-resolves but presents an expired cert for a defunct name.

First response

ERR_CERT_COMMON_NAME_INVALID appears when the hostname does not match CN or SAN, sometimes alongside expiry. Inspect the served names and renew a certificate that covers the live URL.

Search interest in ERR_CERT_COMMON_NAME_INVALID rises when the leaf notAfter on the hostname customers type is already in the past. Clients cannot rewrite server certificate dates; they only accept chains that pass PKIX checks at handshake time.

For ERR_CERT_COMMON_NAME_INVALID hostname errors, prove the failure from outside your office VPN before you change application code, purge caches, or ask end users to reboot. Capture the broken serial number and notAfter, renew on the listener that actually terminates that name, reload every node in the path, then re-run the same OpenSSL and browser checks that opened the incident.

Escalations for err-cert-common-name-invalid should cite fresh openssl subject= and -text SAN section against typed hostname output before anyone edits client code or blames Wi‑Fi. ERR_CERT_COMMON_NAME_INVALID appears when the hostname does not match CN or SAN, sometimes alongside expiry. Inspect the served names and renew a certificate that covers the live URL. When ERR_CERT_COMMON_NAME_INVALID alongside stale certs clusters around Browsers after hostname verification, the expired material is usually bound to certificates missing SAN for the live URL instead of a mysterious platform bug. Executive summaries need the public hostname and current notAfter, not screenshots from a VPN-split test laptop.

See also ERR_CERT_AUTHORITY_INVALID explained and Multi-domain SAN certificate: one name expired?.

What this error means

Browsers compare the requested host to SAN entries (CN is legacy). Wildcard coverage is limited to one label; nested hosts need explicit SANs.

Load balancers may attach a default cert whose names do not include your vanity domain, triggering mismatch while another vhost still holds a valid file on disk.

Reissue including all live hostnames, deploy to the listener answering public DNS, and verify both name coverage and future notAfter.

In PKIX terms, Browsers after hostname verification treat the TLS Certificate message as authoritative: signatures must verify, each link must be within notBefore/notAfter, and only then does name matching run against CN and SAN. When the leaf expired, ERR_CERT_COMMON_NAME_INVALID alongside stale certs is expected even if the issuer is publicly trusted. Guides titled err cert common name invalid still require reading dates on every certificate the server sends, including forgotten cross-sign intermediates.

Triage for err cert common name invalid should reject quick myths: flushing DNS or rebooting laptops does not move server notAfter forward. It is not proof the whole internet is broken when other HTTPS sites load for Browsers after hostname verification. It is not interchangeable with registrar billing lapses unless revalidation fails later. It is not fixed by turning off TLS at the load balancer while marketing keeps publishing https:// links. Validated externally, openssl subject= and -text SAN section against typed hostname must show fresh dates on certificates missing SAN for the live URL before you close the incident.

Common causes

These patterns appear often during ERR_CERT_COMMON_NAME_INVALID incidents. They are not exhaustive, but they explain why renewal looked finished internally while strangers still received expired material.

Runbooks for err cert common name invalid most often break at handoff: certbot or a vendor portal issued new certs, but certificates missing SAN for the live URL never received a reload. Teams tracked PEM files in git while production continued serving the previous listener binding. OV renewals waited on legal approvers until ERR_CERT_COMMON_NAME_INVALID alongside stale certs became customer-visible. Inventory spreadsheets omitted the hostname that Browsers after hostname verification actually call during peak traffic.

Architecture amplifies err cert common name invalid: multiple regions, canary pools, or blue/green deploys can leave one ASG member presenting yesterday's fullchain. Shared IP default certificates silently terminate vanity hostnames without dedicated SNI rules. Mounted TLS secrets updated on disk while Envoy or nginx workers kept the old chain until signaled. ERR_CERT_COMMON_NAME_INVALID appears when the hostname does not match CN or SAN, sometimes alongside expiry becomes harder to debug when only a fraction of Browsers after hostname verification hit the stale anycast node.

Measurement gaps complete the story for err cert common name invalid. Synthetic monitors that disable certificate verification greenlit deploys that fail for real Browsers after hostname verification. Redirect maps hid which hop expired until operators ran openssl subject= and -text SAN section against typed hostname per hostname. Dashboards celebrated TCP uptime while notAfter crossed midnight UTC without a page. Post-mortems should ask whether CT logs or stapled OCSP would have warned days earlier.

Confirm from the outside

OpenSSL

echo | openssl s_client -connect HOST:443 -servername HOST 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Compare subject= CN and SAN against the URL bar host.

How to read the output

Start with openssl subject= and -text SAN section against typed hostname against the live customer hostname, capturing the leaf presented after SNI selection. Interpret notBefore= and notAfter= first: past notAfter guarantees failure for ERR_CERT_COMMON_NAME_INVALID alongside stale certs regardless of pretty issuer branding. Next read subject= and any X509v3 Subject Alternative Name extension for alignment with the URL bar. Finally note issuer= so you know whether renewal changed intermediates; record serial numbers in the ticket for post-deploy diffing.

curl

curl -vI --connect-timeout 10 https://HOST/ 2>&1 | grep -Ei 'expire|SSL certificate|subject:|issuer:'

curl shows SSL certificate problem: certificate doesn't match hostname when SNI hits wrong vhost.

Browser spot-check

Error text distinguishes mismatch from expiry; still inspect dates after naming is fixed.

Fix checklist

Work this list in order for err_cert_common_name_invalid hostname errors. Each step should produce evidence (command output, timestamps, serial numbers) you can paste into the incident ticket.

1. List every redirect hostname in the flow.
2. Compare SAN list to live DNS names.
3. Reissue CSR with complete SAN set.
4. Bind cert to correct vhost/SNI on LB.
5. Remove default cert fallbacks that steal traffic.
6. Renew if existing cert is also expired.
7. Test apex, www, and regional subdomains.
8. Update CDN alternate names if applicable.

Roll out and verify

Procurement for err cert common name invalid begins with a reissue that lists every hostname Browsers after hostname verification need, including forgotten admin and callback URLs. Validate CSR/key pairs, download CA bundles, and schedule work on certificates missing SAN for the live URL during a staffed change window. If automation handles ACME, prove challenges use the same DNS names customers resolve publicly, not internal-only labels.

Installation for err cert common name invalid means concatenating leaf and required intermediates the way your stack documents, then touching every node that terminates the name. Reload web servers, recycle ingress pods, or update cloud listener objects so data planes read new bytes. For load balancers, sync default and per-host certificates so SNI cannot fall back to expired defaults. Repeat openssl subject= and -text SAN section against typed hostname until fingerprints or serials change everywhere responders tested earlier.

Verification for err cert common name invalid must mimic strangers: external synthetics, mobile carriers, and CI jobs without corporate trust roots. Confirm ERR_CERT_COMMON_NAME_INVALID alongside stale certs disappeared for Browsers after hostname verification on flows heavier than GET /. Restore any strict TLS, HSTS, or CDN SSL modes relaxed during firefighting. Feed the hostname into continuous notAfter monitoring with thresholds well before the next CA-enforced renewal cliff.

What to automate

Certificate files on disk lie. Automate live TLS checks on the exact hostname and port users hit, including redirects and the certificate presented after TLS terminates on a load balancer or CDN. Pair certificate notAfter with RDAP domain registration expiry so re-validation is not blocked by a lapsed registrar.

Detect SAN drift when DNS adds new marketing subdomains. Schedule alerts at 30, 14, 7, and 1 day before expiry so on-call has runway for ACME failures, manual OV revalidation, or change windows. Services such as ssldays can run external checks and renewal reminders without replacing your CA workflow.