APNs certificate renewal: why the same Apple Account matters

What the MDM push certificate does

An MDM server cannot reach into a device on its own. Instead, devices keep a persistent connection to Apple Push Notification service (APNs), and the MDM server uses APNs to send a small notification that tells a device it has something waiting. The device then checks in with the MDM server over HTTPS and picks up the work. The notification is only a prompt to check in.

The MDM push certificate (often just called the APNs certificate) is what authorizes your MDM server to send those notifications. Without a valid one, the server has no way to wake devices. Apple lists it alongside the other certificates a management service needs, such as a TLS certificate for secure communication and a certificate for signing configuration profiles.

How the certificate is created

The process has a fixed shape, whichever MDM product you use:

1. A certificate signing request (CSR) is generated and signed by the MDM service. In AAMDM you download it from your workspace’s Apple connections, as the setup guide shows. Apple requires SHA-2 signing for the CSR, and requests signed with SHA-1 are rejected.
2. You sign in to the Apple Push Certificates Portal at identity.apple.com/pushcert with an Apple Account (Apple recommends a Managed Apple Account) and upload the signed CSR.
3. The portal issues a certificate, which you download as a .pem file.
4. You upload that file to your MDM server, which can now send pushes through APNs.

The certificate is tied to the account you used in step 2. That detail is the reason this article exists.

One-year validity and what expiry does

Apple states that the push certificate must be renewed every year, and advises renewing and updating all management certificates well before they expire. Treat the expiration date as a hard deadline, not a suggestion.

If the certificate expires, devices stop receiving updates from your MDM server until a renewed certificate is installed. In practice that means:

• Commands and policy changes you send no longer reach devices promptly, or at all.
• Lock, wipe, and app or profile changes cannot be triggered on demand, which matters most when a device is lost.
• Your console may still list the devices as enrolled, so the fleet can look normal until you try to act on it.

Apple’s documentation describes the outcome as devices not receiving updates until a renewed certificate is imported. How you renew matters, which is the next point.

Renew with the same Apple Account

The Apple Push Certificates Portal lists the certificates created under your account. Each shows an expiration date and a unique identifier, and each has a Renew option. Apple describes it this way: click Renew to reissue a certificate with the same Apple ID, but with an extended expiration date. Apple’s deployment guide adds that push certificates are renewed using a Managed Apple Account or Apple Account in the Apple Push Certificates portal. Renew the certificate you already have, with the account that created it. That is the path Apple documents, and it is the one AAMDM follows.

Apple’s warnings cover two cases. If you lose access to the Managed Apple Account or Apple Account used to create the push certificate, Apple says you may need to reenroll your devices to restore management connectivity. And if the certificate expires, devices cannot receive updates from your MDM until an updated certificate is installed. Apple’s documentation does not describe what happens to enrolled devices if you create a brand-new certificate instead of renewing, so AAMDM’s rule is simple: renew, never replace, and never experiment on a production fleet.

Who should own the Apple Account

The most common cause of an avoidable APNs incident is a certificate created by one person with their own Apple Account. That person changes roles, leaves, or forgets the password, and the renewal date arrives with nobody able to sign in.

• Use a company-owned account, not an individual's personal Apple Account. Apple recommends a Managed Apple Account where one is available.
• Make the sign-in recoverable by more than one person: a shared mailbox for the account email, and a documented process for two-factor codes.
• Record the account name, the certificate identifier, and the expiration date in your runbook, and name an owner and a backup owner.
• Do not tie it to a named employee's address. Use a role address such as an IT mailbox that survives staff changes.

If your certificate is already tied to a personal account, do not rush to create a replacement. Apple provides Deployment Programs Support for help with APNs certificates; see Apple’s contact page. For a new AAMDM workspace, start with a company-owned account so you never face this.

Reminders and a renewal checklist

Do not rely on a single email from Apple or from us. Put the expiration date on a shared calendar with alerts at 60, 30, and 7 days, assigned to the owner and the backup. Renewing a few weeks early is free and removes the deadline pressure.

A renewal usually takes ten minutes if the steps are written down:

1. Open your MDM console and generate a fresh signed CSR for renewal (the exact step varies by product).
2. Sign in to identity.apple.com/pushcert with the original Apple Account.
3. Find the existing certificate by its expiration date and identifier, and choose Renew.
4. Upload the new CSR and download the .pem file.
5. Upload the .pem to your MDM console, replacing the current certificate. Do not delete the existing connection first.
6. Confirm the console shows the new expiration date, then send a harmless command to a test device and verify it arrives.
7. Update the runbook and reset the calendar reminders for next year.

Common mistakes

• Giving up on finding the original Apple Account instead of contacting Apple for help with the certificate.
• Signing in to the portal with a different account than the one used originally, then not noticing the certificate list is empty or different.
• Letting a departed employee's account be the only owner.
• Renewing in the portal but forgetting to upload the new .pem to the MDM server.
• Skipping the post-renewal test, so a failure surfaces months later during an incident.
• Blocking APNs traffic at the firewall. Apple documents TCP 5223 for devices (with 443 as a fallback) and 443 or 2197 for the MDM server's outbound pushes, so check these when pushes fail even though the certificate is valid.

Sources

• Apple Platform Deployment: Configure devices to work with APNs
• Apple Platform Deployment (Education): Ongoing management for Apple devices
• Apple Support: Contact Apple for help with APNs certificates
• Apple macOS Server guide: Push notification certificates (Renew and Change)
• Apple Developer Documentation: Device Management

AAMDM is not affiliated with Apple Inc. Apple documentation changes over time; check the linked pages for the latest details.

Related articles