Android SSL certificate expired errors

When Android Chrome shows a certificate date error, the server’s leaf certificate notAfter is in the past—renew and reload the listener strangers actually reach.

Mobile shoppers rarely report obscure TLS codes; they abandon tabs that refuse to load checkout or login. On Android, Chrome uses the same PKIX rules as desktop Chromium, so an expired server certificate surfaces as a full-page interstitial instead of a quiet retry.

Internal dashboards may still show a green padlock on stale corporate DNS because testers are not on carrier networks. Confirm the public hostname from cellular data or an external monitor before you treat the incident as “only some users.”

First response

Chrome on Android blocks HTTPS when the server leaf certificate is past notAfter. Diagnose expiry, renew TLS, and monitor before users see NET::ERR_CERT_DATE_INVALID.

Search interest in android ssl 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 Android SSL certificate expired 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.

Android incidents spike when marketing pushes deep links that force Chrome to open HTTPS immediately, with no corporate VPN shielding the same DNS answers retail users get. Project managers sometimes request a client-side workaround while operations still has only refreshed PEM files on a staging VIP. That gap wastes hours because PKIX runs before any JavaScript executes. Treat every Android report as a signal to validate the public listener with OpenSSL using the exact hostname and SNI users type, not the internal CNAME your dashboard prefers.

See also Certificate chain incomplete in the browser and Why you should not bypass an expired certificate warning.

What this error means

Android Chrome validates the full chain the server sends during the TLS handshake. If the leaf certificate’s notAfter is before the device’s current UTC time, verification fails and the browser blocks the page. The error text may mention invalid dates even when the underlying problem is simply expiry.

WebViews inside banking and retail apps inherit the same trust store behavior. An expired cert on an API host breaks mobile clients that do not display a helpful message, which makes server-side date checks essential.

Clock skew on a phone can mimic date errors, but widespread Android failures almost always mean the certificate on the server is expired. Fix the material presented on port 443, not the user’s device clock.

Android Chrome and most embedded WebViews use the platform trust store and standard RFC 5280 path validation. When the server presents a leaf whose notAfter predates the handset clock, verification fails with date-related copy even if the issuer is a major public CA. The browser does not consult your CDN dashboard; it only sees the Certificate chain in the TLS handshake. NET::ERR_CERT_DATE_INVALID is Chromium vocabulary for temporal failure on the leaf or an intermediate, but production Android outages are overwhelmingly an expired server certificate on the hostname users requested.

An expired certificate on the server is not fixed by clearing Chrome storage, revoking Wi‑Fi DHCP, or reinstalling the app unless the app also pins obsolete material. It is not equivalent to a captive portal or firewall injection attack when openssl s_client from mobile data shows the same notAfter in the past. It is not proof that Google Play Protect broke trust. It is not resolved by switching from cellular to office Wi‑Fi if both paths hit the same expired listener. It is not a DNS-only failure: A records can resolve while TLS still dies on dates.

Common causes

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

Operations renewed on the origin but the anycast load balancer default certificate expired and still answers a share of carrier traffic. Automation wrote new files under /etc/ssl without running nginx -s reload or recycling ingress pods. A wildcard PEM expired while per-host certificates on the same IP were renewed separately and never deployed to the default TLS slot.

ACME succeeded on one node in an autoscaling group while older instances kept serving yesterday's fullchain from memory until drained. Mobile-specific hostnames such as m.example.com or api.example.com were omitted from renewal SAN lists during a rushed reissue. Certificate Manager association lag left the listener serving the previous ACM import after the CA already issued a replacement.

Teams tested with curl -k or internal mkcert roots, then promoted the same listener config to production without external PKIX verification. Dual-stack or HTTP/3 experimental listeners used a different certificate map than the primary 443 vhost Android Chrome selects. A delayed intermediate rollover made some Android builds fail earlier than desktop, masking the underlying expired leaf until logs were correlated.

Confirm from the outside

OpenSSL

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

Replace HOST with the site users type in Chrome on Android. Compare notAfter against UTC; if it is yesterday or earlier, renewal must happen on the terminator that answers this name.

How to read the output

Run echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject -issuer. For Android reports, replace example.com with the precise host from the failing URL, including punycode. If notAfter is before current UTC, Android will block regardless of issuer brand. Compare subject CN and Subject Alternative Names to the typed hostname; expiry failures stand alone even when SAN matches. Record issuer DN and serial number in the ticket so reload verification can confirm the new leaf actually reached the edge.

curl

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

curl from a laptop mirrors automation many teams use to probe production. A verbose failure here usually matches what Android sees, which helps you separate Wi‑Fi filtering from genuine expiry.

Browser spot-check

On Android Chrome, open the site, tap the lock (if shown) or the error details, and inspect certificate dates. Screenshot the notAfter field for the ticket; it should match OpenSSL output from outside your VPN.

Fix checklist

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

1. Reproduce on Android Chrome using mobile data, not only office Wi‑Fi.
2. Run external OpenSSL against the customer-visible hostname and SNI name.
3. Identify which load balancer, CDN, or origin presents the expired leaf.
4. Issue a renewed publicly trusted certificate with correct SAN coverage.
5. Deploy full chain (leaf plus intermediates) to the live listener.
6. Reload or roll terminators so all nodes pick up the new bundle.
7. Retest Android Chrome and a common in-app WebView if applicable.
8. Add expiry monitoring on the same hostname mobile apps call.

Roll out and verify

Issue or obtain a renewed publicly trusted certificate whose SAN covers every Android entry hostname, including marketing short links and API hosts called from WebViews. Validate the private key matches the CSR, store the chain zip from the CA, and schedule change management before touching production terminators. If using ACME, confirm HTTP-01 or DNS-01 challenges hit the same names users type on phones, not only apex records.

Install leaf plus intermediates on every node that terminates TLS for those hostnames, using your platform's bundle format. Reload nginx, Apache, HAProxy, Envoy, or cloud listener bindings so running workers pick up bytes, then drain old connections where protocols allow. For container ingress, update the TLS Secret and restart controllers if your distribution does not hot-reload. Confirm the serial number changed with another external openssl s_client from a non-VPN network.

Retest in Android Chrome on mobile data with a cold profile and in any in-app WebView your product uses. Run curl -vI from an external CI runner against the same URLs. Enable or tune automated expiry monitoring on customer-visible names, paging before notAfter crosses into incident territory. Document which listener presented the expired cert so the next renewal targets the correct tier.

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 top mobile entry hostnames separately from admin panels. 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.