Tag Archives: apns

Checking APNs reachability with Nagios

What?!I have deployed a couple of Profile Manager instances where the Apple Push Notification Service (APNs) was reachable at install, but due to some over zealous network administration, connectivity was lost along the way.

The big issue with this is that as a fairly silent failure, it may take a minute to troubleshoot why changes aren’t pushing to devices. If you have your Profile Manager (or other onsite MDM) instance under monitoring however, you can check for reachability at intervals, and have the troubleshooting done for you.

Thus, I have added my APNS reachability script to OSX-Monitoring-Tools. It can be used to ensure that monitored systems can see and connect to Apple’s APNS provider servers, and that clients can connect to receive notifications within the network.

OSX-Monitoring-Tools on GitHub


Workaround for an APNS bug on Lion Server

If you are like me, and have a Lion Server VM that you constantly nuke and pave, you may have run into this one.

A bug exists (likely not in 10.7.3, but actually Apple’s APNS service), that can cause setup of Apple push notifications to fail in either the wider Profile Manager setup assistant, or when signing in to get an APNS certificate in Server.app.

If you use an Apple ID to request a new certificate for the same hostname over and over, it will only work a certain number of times before you get stuck ‘Acquiring’ forever:

In Profile Manager setup, you get the slightly more informative “Getting push certificate status”, but I am yet to find any sort of verbosity in a log anywhere when this occurs.

When this occurs, Apple’s server creates a new certificate for you and then fails somewhere, never returning the newly created certificate. This actually compounds the problem, as too many certs seems to be the issue.

The current fix is to log into the Apple Push Certificates Portal, and revoke any old certificates for the affected hostname. This is obviously a pretty good housekeeping step anyway, but as the identity.apple.com portal is kind of obfuscated from the Server.app request process until you successfully get a certificate, you, as I did, might finally stumble across it, and find it pretty full of old certificates.

I have a radar in to throw a verbose error. I’m pretty sure Apple stopping you at a finite number of certs for a hostname is reasonable, but not failing silently without description would be nice.

For Cupertinoids, rdar://1593419. For everyone else, OpenRadar.