Multi-domain SAN certificate: one name expired?

A multi-domain SAN certificate is one validity period—when it expires, every name on it fails together.

Teams ask if only one SAN expired; PKIX does not work that way. The whole cert is invalid after notAfter.

Partial DNS cutovers magnify pain when the shared cert dies mid-migration.

First response

A SAN certificate is one file: if notAfter passed, every name in the cert is dead. Confirm the served hostname, reissue for the correct names, and redeploy before partial DNS cutovers break.

Search interest in san certificate expired 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 Multi-domain SAN certificate: one name expired?, 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 san-certificate-partial-expiry should cite fresh openssl -text showing one validity window for all names output before anyone edits client code or blames Wi‑Fi. A SAN certificate is one file: if notAfter passed, every name in the cert is dead. Confirm the served hostname, reissue for the correct names, and redeploy before partial DNS cutovers break. When multi-name cert confusion during cutovers clusters around Operators assuming per-SAN expiry, the expired material is usually bound to single notAfter governing every SAN entry 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 ERR_CERT_COMMON_NAME_INVALID hostname errors.

What this error means

All DNS names listed in SAN share leaf expiry. Reissue covers the full set or split certs per hostname.

Removing a name from DNS does not remove it from cert needs until you reissue.

Plan SAN list carefully on renewal, deploy fullchain, verify each live name with openssl.

In PKIX terms, Operators assuming per-SAN expiry 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, multi-name cert confusion during cutovers is expected even if the issuer is publicly trusted. Guides titled san certificate partial expiry still require reading dates on every certificate the server sends, including forgotten cross-sign intermediates.

Triage for san certificate partial expiry 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 Operators assuming per-SAN expiry. 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 -text showing one validity window for all names must show fresh dates on single notAfter governing every SAN entry before you close the incident.

Common causes

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

Runbooks for san certificate partial expiry most often break at handoff: certbot or a vendor portal issued new certs, but single notAfter governing every SAN entry 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 multi-name cert confusion during cutovers became customer-visible. Inventory spreadsheets omitted the hostname that Operators assuming per-SAN expiry actually call during peak traffic.

Architecture amplifies san certificate partial expiry: 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. A SAN certificate is one file: if notAfter passed, every name in the cert is dead becomes harder to debug when only a fraction of Operators assuming per-SAN expiry hit the stale anycast node.

Measurement gaps complete the story for san certificate partial expiry. Synthetic monitors that disable certificate verification greenlit deploys that fail for real Operators assuming per-SAN expiry. Redirect maps hid which hop expired until operators ran openssl -text showing one validity window for all names 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

-ext subjectAltName shows every covered host.

How to read the output

Start with openssl -text showing one validity window for all names against the live customer hostname, capturing the leaf presented after SNI selection. Interpret notBefore= and notAfter= first: past notAfter guarantees failure for multi-name cert confusion during cutovers 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:'

Test each SAN host with curl -vI separately.

Browser spot-check

Each subdomain interstitial should clear after unified renewal.

Fix checklist

Work this list in order for multi-domain san certificate: one name expired?. Each step should produce evidence (command output, timestamps, serial numbers) you can paste into the incident ticket.

1. Export current SAN list from live cert.
2. Drop unused names to simplify renewal.
3. Add new hosts before reissue.
4. Validate domain control for all names.
5. Deploy renewed cert to all terminators.
6. Spot-check top revenue SANs first.
7. Update documentation of shared cert consumers.
8. Consider splitting high-risk hosts to own certs.

Roll out and verify

Procurement for san certificate partial expiry begins with a reissue that lists every hostname Operators assuming per-SAN expiry need, including forgotten admin and callback URLs. Validate CSR/key pairs, download CA bundles, and schedule work on single notAfter governing every SAN entry 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 san certificate partial expiry 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 -text showing one validity window for all names until fingerprints or serials change everywhere responders tested earlier.

Verification for san certificate partial expiry must mimic strangers: external synthetics, mobile carriers, and CI jobs without corporate trust roots. Confirm multi-name cert confusion during cutovers disappeared for Operators assuming per-SAN expiry 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.

Track SAN count and per-name revenue weight in alerts. 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.