Apple Push Service certificate is not trusted
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
If an Apple Push Service certificate shows as not trusted, the problem is usually in the certificate chain, the local keychain trust store, or the way the certificate was exported and installed. The message does not automatically mean Apple issued a bad certificate.
It means the current machine or server cannot build a trust path it accepts. That is a certificate-management problem, not an APNs protocol problem.
What the Certificate Is For
Older APNs provider setups commonly used an APNs SSL certificate and private key to authenticate with Apple push servers. When the certificate or trust chain is wrong, the provider connection fails before notifications can be sent.
Typical causes include:
- expired APNs certificate
- missing Apple intermediate certificate
- private key mismatch after export/import
- stale or broken trust state in Keychain Access
- server using the wrong environment certificate
Start with the Basics
Check:
- the certificate expiration date
- whether the private key is attached
- whether the full Apple chain is present
- whether the certificate is for development or production
If the certificate appears in Keychain without its private key, the export/import process is incomplete and the push provider will not authenticate correctly.
Inspecting the Trust Chain
On a macOS machine, Keychain Access is the first place to inspect the certificate. Expand the certificate entry and confirm that the private key is nested underneath it.
On a server or CI machine, openssl helps inspect the chain:
That command lets you verify whether the P12 bundle actually contains the certificate and private key material you expect.
Re-Exporting a Clean P12
If the certificate is valid in Keychain but fails after installation elsewhere, export it again from the Mac where it was created:
- select the certificate and its private key together
- export as
.p12 - protect the export with a password
- import that P12 on the destination server
Many "not trusted" reports are really incomplete exports or server-side import mistakes.
Consider Token-Based APNs Auth
For modern APNs provider implementations, token-based authentication with an APNs auth key is often preferable to certificate-based auth. It reduces certificate rotation burden and avoids some of the legacy trust-chain pain points tied to P12 management.
That does not fix a broken certificate directly, but it is worth considering if you are still building around older certificate workflows.
Verify the Environment Match
Even a trusted certificate can still be the wrong one for the server environment. Development and production push credentials are not interchangeable. If a team exports the wrong APNs certificate and installs it on the provider side, the setup may look correct in storage but still fail during push setup or connection attempts.
Common Pitfalls
- Using an expired APNs certificate and blaming the server.
- Importing the certificate without its private key.
- Mixing development and production credentials.
- Assuming the trust problem is inside APNs when the local trust store is incomplete.
- Persisting with certificate-based auth when token-based APNs auth would simplify operations.
Summary
- "Not trusted" usually means the local machine cannot validate the certificate chain.
- Check expiration, private-key presence, and Apple intermediate certificates first.
- Export and import the P12 carefully if the certificate is being moved between machines.
- Development and production APNs credentials are different and must not be mixed.
- For modern systems, APNs token-based auth is often easier to operate than certificate-based auth.
