APNs certificate

An APNs certificate (shown as "Apple Push Services" in the portal) is the certificate-based way to authenticate a push server to Apple Push Notification service. Your backend presents it in a mutual TLS handshake when connecting to APNs. One certificate covers one app, handles both the sandbox and production environments, and expires after a year. It is the older of the two APNs credentials; the modern alternative is the APNs auth key, a .p8 that never expires.

Why it causes outages

The app in the store keeps running when the certificate expires. Only pushes stop: APNs refuses the TLS connection, the backend logs certificate errors, and notifications silently stop arriving. Because nothing visible breaks, teams often find out from users asking why notifications stopped. Third-party push providers (Firebase Cloud Messaging, OneSignal, Braze) sit in the same boat if they were configured with a certificate instead of a key.

Renewing without downtime

1. 1

   Create the new certificate before the old one expires

   In the portal, create a new Apple Push Services certificate for the same App ID. Apple allows two active push certificates per app precisely so they can overlap during rotation.

2. 2

   Export it as a .p12 and install it on the sender

   Download the .cer, combine it with its private key into a .p12, and upload that to your push backend or provider. The old certificate keeps working while you do this.

3. 3

   Confirm delivery, then revoke the old one

   Send test pushes to sandbox and production through the new certificate. Once delivery is confirmed, revoke the expiring certificate.

Certificate or auth key?

For new projects the auth key wins outright, and every major push provider accepts it. Certificates persist mostly in older systems that were set up before token auth existed, and in the rare environment whose tooling only speaks mutual TLS. If you are renewing a push certificate for the second time, that is usually the moment to migrate to the key instead.