Apple push notification certificate expired

Mobile users report “notifications stopped working” while the app still opens—apns certificate expired provider credentials mean Apple's gateway rejects your TLS client authentication even though your marketing site certificate is fine.

Push providers (SNS, Firebase with APNs, home-grown Node workers) open a mutually authenticated TLS session to gateway.push.apple.com or the sandbox host. Apple-issued provider certificates carry a hard one-year notAfter for the legacy PEM workflow; HTTP/2 token-based keys do not replace expired legacy certs until you migrate.

Teams often monitor api.example.com but not the PEM mounted on the worker that only talks to Apple. Incident tickets blame the mobile release when OpenSSL on the push box shows yesterday's provider expiry.

First response

Record app bundle ID, environment (sandbox vs production), push worker hostname, and the exact OpenSSL or library error (certificate has expired, bad certificate, connection reset). Export the provider PEM or PFX and read dates locally before touching Apple Developer.

openssl x509 -in apns_provider.pem -noout -dates -subject

Match subject OU and CN patterns to the Apple Developer certificate list. Capture whether you use legacy binary provider cert vs APNs Auth Key (.p8)—only the legacy path hits apns certificate expired on the client cert Apple issued.

What this error means

APNs legacy provider TLS requires your server to present an Apple-signed client certificate during handshake. When that certificate's notAfter passed, Apple closes or rejects the connection; devices never see a payload.

This is separate from the TLS certificate on your public REST API. Users browsing HTTPS to your backend succeed while push daemons silently fail in a background queue. Firebase and other bridges still ultimately present Apple provider material unless fully on token auth.

Sandbox and production use different gateway hostnames and different provider certificates. Renewing production while sandbox still mounts last year's PEM explains “works in TestFlight, dead in App Store” patterns.

Silent failure is the operational hazard. Crash reporting and mobile analytics often show healthy sessions because the app foreground path never exercises push delivery. Marketing notices open rates drop days before engineering correlates OpenSSL dates on provider PEM material.

Mutual TLS on the provider channel means your client certificate expiry breaks the session even when Apple's server certificate is valid and trusted worldwide. Incident triage that openssl only the gateway hostname misattributes failures to Apple infrastructure.

Throughput limits and topic entitlements remain enforced only after authentication succeeds. An expired provider cert can masquerade as throttling or invalid device token errors until you inspect the worker TLS context directly.

Common causes

Apple Developer portal shows a new provider cert, but only one push worker in an autoscaling group received the updated secret mount. Chef or Puppet deployed the PEM to disk while the JVM or Erlang VM kept the old cert in memory until restart.

Ops renewed the wrong app ID certificate (Apple Development or Distribution) instead of Apple Push Notification service SSL. CI still packages the expired aps P12 from a secrets vault version pinned years ago.

Migration to APNs Auth Keys stalled halfway: some regions use JWT, one legacy datacenter still loads expired PEM. Cron-driven renewal reminders targeted web certs, not push-specific Apple one-year limit.

Blue-green push deployments that share a vault namespace can leave the inactive color on the previous PEM until traffic switches, then flip an entire region at once when color promotion happens without rolling workers.

Bundle ID mismatch between the App ID used to create the provider cert and the topic your sender declares causes auth rejection that looks like expiry in casual logs. Always line up portal App ID, cert subject, and sender topic before blaming dates alone.

Kubernetes ExternalSecrets sync delays after vault update leave pods that restarted individually on old mounts while the cluster believes rotation completed. Force rollout every deployment that mounts push credentials, not only the canary namespace.

Confirm from the outside

Local PEM dates

openssl pkcs12 -in apns.p12 -nodes -passin pass:EXPORT_PASSWORD 2>/dev/null | openssl x509 -noout -dates -subject

Never commit passwords; run on a hardened admin host.

Gateway handshake probe

openssl s_client -connect gateway.push.apple.com:443 -cert apns_provider.pem -key apns_provider.key -servername gateway.push.apple.com </dev/null 2>&1 | grep -Ei 'Verify|expire|error'

Use sandbox host gateway.sandbox.push.apple.com for non-production. A successful verify with current dates confirms Apple accepts your provider identity.

How to read the output

Verify return code zero with future notAfter on your leaf means provider auth is healthy. Expiry shows in your exported cert dates even when the gateway RSA cert is fine—do not confuse Apple's server cert with your client cert.

Compare notBefore on the provider cert with your last portal download timestamp. If download was recent but notAfter is still past, you exported the wrong row from Developer or merged old and new chain files accidentally.

Application logs

Search push workers for certificate expired, SSLHandshakeException, or HTTP/2 GOAWAY after credential rotation windows.

Add a synthetic send from each region's worker after any secret change. Regional isolation prevents a single success in primary from masking stale PEM on secondary senders behind geo DNS.

Fix checklist

1. In Apple Developer → Certificates, create a new Apple Push Notification service SSL cert for the correct App ID (or migrate plan to APNs Auth Key).
2. Download, install in Keychain, export .p12, convert to PEM/key pair your stack expects.
3. Update secrets in vault/Kubernetes and roll every push worker instance.
4. Restart daemons so in-memory SSL context reloads (not only filesystem replace).
5. Send test notification via npx apns2/houston or your vendor console to sandbox then production.
6. Revoke the old provider cert in Apple Developer after traffic is stable (optional hygiene).
7. Document annual Apple push cert expiry in the same calendar as code-signing if still on legacy path.
8. Archive openssl dates and a redacted screenshot of the new cert row in the portal.

Plan sandbox validation before production cutover when millions of devices depend on daily pushes. A short sandbox window with controlled device tokens catches PEM format mistakes that would bulk-fail production.

Capture before and after device token failure rates from your push vendor dashboard. Gradual recovery after fix confirms workers picked up secrets; an instant cliff suggests remaining instances still bound to old material.

If you migrate to Auth Keys during this incident, schedule parallel runs: legacy PEM until all senders support JWT, then retire portal provider cert to avoid dual-maintenance fatigue next year.

When to use automation

Website TLS monitoring will not catch apns certificate expired because no browser hits the provider PEM. Track expiry on exported push credentials in your secrets manager and alert owners 30+ days before Apple's one-year cliff.

For any hostname you do terminate publicly (device API, universal links), use /check for live TLS plus scheduled reminders. Long term, APNs Auth Keys remove yearly provider cert churn—until migration completes, treat push PEM notAfter as production-critical inventory.