Apple Push Notification service certificates are valid for one year and must be renewed annually in the Apple Developer Portal to avoid interrupting device communication. If you’re responsible for a Capacitor app, an expired or revoked credential can stop notifications even while the app itself appears healthy.
The failure often surfaces at the worst possible time. A release goes out, a campaign is scheduled, and notification delivery suddenly falls silent. Your application server may still accept jobs, but APNs can reject the TLS connection before a message reaches a device. The practical fix isn’t just creating another certificate. You need to understand which APNs credential your system uses, preserve the private key, plan the renewal, and move suitable workloads to token-based authentication.
Table of Contents
- Why Push Notifications Stop Working
- Creating and Downloading Your APNs Certificate
- Exporting the Certificate to a Private Key
- Migrating to the New Token-Based Authentication
- Renewing and Managing Certificate Lifecycles
- Troubleshooting and Handling Lost Credentials
Why Push Notifications Stop Working
APNs sits between your provider server and the user’s Apple device. Your server authenticates to Apple, submits a notification, and relies on APNs to route it to the registered application and device. If the credential is expired, revoked, associated with the wrong identity, or installed incorrectly, the request can fail before delivery begins.
Apple states that APNs keeps a revoked-certificate list and refuses TLS connections from servers using certificates on that list. That makes certificate hygiene a delivery requirement, not an administrative preference. The server may continue processing notification jobs locally, while Apple rejects the provider connection.
Separate app push from MDM push
The first diagnostic question is simple: which service are you trying to operate?
| Credential path | What it does | Typical owner |
|---|---|---|
| App Push | Sends alerts and other application notifications to end-user devices | Mobile or backend engineering |
| MDM Push | Lets a device-management platform communicate with managed Apple devices | IT, endpoint, or enterprise mobility administration |
These credentials aren’t interchangeable. An MDM platform can lose contact with enrolled devices when its MDM push credential expires, while an application backend can lose notification delivery because its App Push credential is invalid. Treating both as one “Apple push certificate” problem sends troubleshooting in the wrong direction.
For Capacitor and Ionic teams, the relevant path for user-facing alerts is generally App Push. The app still needs the Push Notifications capability, correct signing, device registration, and a backend that sends through the appropriate APNs environment. If your team is also shipping over-the-air web assets, keep that release workflow separate from push authentication. The Capacitor notifications plugin documentation covers the application-side integration, while APNs credentials belong in the provider configuration.
Start with the rejection, not the UI
Check the APNs response from your provider server before changing notification copy or rebuilding the app. Then verify the bundle identifier, credential identity, environment, and certificate status. A notification permission problem affects a user’s ability to see alerts, but it doesn’t explain a TLS rejection from APNs.
If the failure appeared after a release, compare the signing and entitlements in the new build with the previous build. If it appeared without an app change, inspect certificate expiration, revocation, trust-store changes, and deployment secrets first. For a broader implementation path, see this guide to Expo push notification setup.
Creating and Downloading Your APNs Certificate
A push rollout can fail before the first notification is sent if the certificate is issued for the wrong App ID or the private key stays on another Mac. Apple’s workflow has two parts: your machine creates a Certificate Signing Request, or CSR, and Apple signs it for the selected App ID. The CSR is not the server credential. It connects the issued certificate to a private key created locally.
Prepare the App ID
Sign in to the Apple Developer portal and open Certificates, Identifiers & Profiles. Select Identifiers, choose the app’s bundle identifier, and open its configuration. Confirm that Push Notifications is enabled before issuing anything.
APNs credentials are tied to the application identity. Do not choose a nearby bundle identifier with a similar name. Configure each separate application independently and issue the matching credential.
On the Mac that will retain the key, open Keychain Access and create the CSR, or use your organization’s approved certificate tooling. Keep the request file and private key under the same controlled ownership. If another administrator creates the CSR, that administrator may hold the private key required later for a usable server bundle.
Issue the signed certificate
In Certificates, choose the Apple Push Notification service certificate option. Select the App ID, upload the CSR, and submit the request. Download the certificate Apple issues.
Double-click the downloaded file on the Mac that owns the private key. It should install in Keychain Access, where you can verify the certificate and its matching private key. A certificate imported without that key cannot provide the complete credential your backend needs.
Use a naming convention that records the application identity, environment, owner, and expiration details. Store the original certificate, CSR ownership information, and portal account details in your team’s credential system. A developer’s Downloads folder or personal laptop is not an operational backup.
The certificate supports only one part of delivery. The app must register for remote notifications, the server must retain the resulting device token, and the provider must send with the matching topic and environment. Keep those dependencies in the same runbook. For client-side setup, see the Capacitor notifications integration guide. Treat this certificate as a managed credential, not a one-time download, because later export, token migration, renewal, and recovery depend on knowing who controls its key.
Exporting the Certificate to a Private Key
A downloaded Apple certificate isn’t automatically ready for a Node.js service or a managed push provider. The server needs the certificate and its corresponding private key, commonly packaged as a PKCS#12 .p12 file.
Open Keychain Access on the Mac where you installed the certificate. Search for the APNs certificate, expand or inspect it, and locate the private key with the matching identity and expiration information. Select the certificate and private key together, then use the export action to save a .p12 file.
Validate the bundle before deployment
Give the export a strong password. The password protects the private key inside the bundle, so don’t place it in a repository, ticket, chat message, or build log. Upload the file and password through your secret-management system, then grant access only to the service that sends notifications.
Practical rule: A
.p12file without its matching private key is not a complete provider credential.
Before production use, test the bundle in a controlled environment. Confirm that your backend can load the file, establish the APNs connection, and return structured errors when Apple rejects a request. If a provider such as Capgo asks for an iOS push credential, upload the .p12 and its password through the designated secret configuration rather than embedding either value in application code.
The format also exposes the weakness of the legacy workflow. You must preserve the original private key, repeat a manual export, protect the file, and replace the deployment secret at renewal time. Teams operating several apps can easily lose track of which bundle belongs to which App ID.
Use secure secret management in CI/CD pipelines to control who can read or replace the credential. Keep an audit trail for uploads and rotations, but never log the private key or the .p12 password.
For new backend work, evaluate whether certificate authentication is still appropriate. Existing integrations may require .p12, but token authentication usually removes the annual certificate replacement from the provider connection. That doesn’t eliminate credential governance. It changes what you protect and rotate.
Migrating to the New Token-Based Authentication
Apple has moved APNs authentication toward provider tokens, commonly called the p8 workflow. Instead of presenting a certificate and private key for a long-lived TLS identity, your provider signs authentication tokens with an Apple Push Notification service Authentication Key.
Create the key in the Apple Developer portal under Certificates, Identifiers & Profiles, then open Keys and register an APNs authentication key. Download the .p8 file and record the associated Key ID and Team ID in your secret store. Treat the downloaded file as a high-value signing secret.
Make the migration deliberately
Don’t switch production traffic by replacing a file in an untested environment. Build token authentication beside the existing certificate path, validate sandbox and production behavior, and compare APNs responses. Then make the provider configuration change during a controlled deployment.
The migration removes the certificate renewal and Keychain export steps from the sending path, but your team still needs a clear ownership model. Decide who can create, revoke, and deploy keys. Limit access to the backend service that signs provider tokens, and make sure an emergency replacement process exists before the current key becomes unavailable.
For a Capacitor app, the client still needs correct notification registration and entitlements. The migration primarily changes server-to-APNs authentication, not the device token registration code. Your backend must continue associating tokens with the correct application and environment.
Know when certificates remain necessary
Some enterprise tools and established integrations still expose certificate-based configuration. Don’t force a p8 migration until the receiving system supports it and your team has tested the complete path. Keep the legacy credential protected during the transition, but don’t create new dependencies on it when token authentication fits.
If you need to understand the surrounding application flow, review Ionic and Capacitor push notifications with Firebase. Firebase can provide an application delivery layer, but Apple credentials, entitlements, registration, and APNs responses still require deliberate configuration.
Renewing and Managing Certificate Lifecycles
Treat an APNs certificate as an expiring production dependency from the day you create it. Apple says these certificates are valid for one year from creation and must be renewed before expiration to preserve device communication. Apple also warns that failing to renew can require users to reregister iOS, iPadOS, and Mac devices with APNs and can cause service interruptions. See Apple’s push notification certificate renewal documentation.
The renewal path is precise:
- Generate a new CSR: Create the request through your approved workflow and preserve the associated key material.
- Use the original Apple ID: Sign in with the same Apple ID used to create the existing certificate.
- Select the expiring certificate: Match the App ID, Subject DN, UID, and expiration details before selecting Renew.
- Upload the CSR: Submit the new request in the Apple Push Certificates Portal.
- Download and reinstall: Retrieve the renewed
.pem, install it where the private key is available, and export a replacement.p12if your provider requires it. - Deploy and test: Update the server secret, send a controlled notification, and inspect the APNs response.
Compare the provider formats
| Requirement | Certificate workflow | Token workflow |
|---|---|---|
| Primary secret | Certificate plus private key | .p8 authentication key |
| Renewal concern | Certificate expiration requires recurring replacement | No annual certificate replacement |
| Deployment work | Install, pair, export, and upload | Store signing key and configure token generation |
| Main failure risk | Wrong certificate, missing private key, expiry, or revocation | Lost, exposed, or revoked authentication key |
Apple’s certificate ecosystem has also required scheduled trust-chain work. Apple announced APNs server-certificate updates for sandbox on January 20, 2025 and production on February 24, 2025, requiring trust stores to include the SHA-2 Root USERTrust RSA Certification Authority certificate. Read the Apple APNs server-certificate announcement and make trust-store ownership part of your platform checklist.
Use a shared renewal calendar, a named owner, and a deployment runbook. The Capgo certificate management documentation can sit alongside that runbook for teams managing iOS delivery credentials with their mobile release process.
Troubleshooting and Handling Lost Credentials
The difficult incident isn’t always an expiration warning. It’s the morning when the administrator who created the certificate has left, the private key exists only on an old Mac, or a certificate was revoked during an attempted cleanup. The standard renewal flow depends on the original Apple ID and the correct certificate identity, so access and provenance matter as much as the file itself.
Start by classifying the failure:
- Expired certificate: Generate a replacement through the original account, reinstall it with the matching private key, update the provider, and test delivery. If device communication has already been interrupted, follow Apple’s recovery guidance rather than assuming a server-side replacement instantly restores every device.
- Revoked certificate: Stop treating the old credential as recoverable. Apple refuses TLS connections from servers using revoked certificates, so create a valid replacement and remove the revoked secret from active deployments. Check who revoked it and whether other systems copied the same credential.
- Lost
.p12password: A certificate file without the usable password may be operationally unavailable. Retrieve the approved backup or issue a replacement instead of weakening production secret controls. - Lost private key: Re-downloading the public certificate won’t recreate the private key. Create a new CSR on a controlled machine and issue a replacement credential.
- Lost Apple ID access: Confirm whether the organization can recover the account through its identity and deployment processes. Apple directs support for APNs certificates created through the relevant portal to Deployment Programs Support.
Recovery requires identity, not just a filename. Record the Apple ID owner, App ID, certificate identity, private-key location, provider configuration, and replacement procedure before an incident occurs.
Build an operational safety net
Put certificates and .p8 keys in a shared, access-controlled vault. Store the .p12 password separately from the file, restrict production access, and document the exact portal account used for renewal. Your CI/CD system should inject secrets at deployment time and run a health check that detects authentication failures before users report missing alerts.
Keep the old credential available during a controlled replacement when the platform permits it, but don’t leave obsolete secrets active indefinitely. Test a replacement in the same backend path that production uses, including the provider’s environment, bundle identifier, and device-token store.
When an outage has already happened, preserve APNs response bodies and timestamps, identify the first rejected request, and compare the deployment secret before and after the incident. Don’t retry indefinitely against an invalid credential. Correct the identity or authentication problem first, then send a small verification notification to a known test device.
Capgo can store and configure iOS push credentials as part of a Capacitor notification workflow, while your team retains responsibility for Apple account access, secret custody, and renewal decisions. Visit Capgo to review how its mobile delivery tooling can fit alongside your APNs credential lifecycle and release process.
