This week, all iOS Developers received an email from Apple, stating:

“On December 22, 2010, the production Apple Push Notification service will begin to use a 2048-bit TLS/SSL certificate that provides a more secure connection between your provider server and the Apple Push Notification service.

To ensure you can continue to validate your server’s connection to the Apple Push Notification service, you will need to update your push notification server with a copy of the 2048-bit root certificate from Entrust’s website. This will not require a change to your iOS apps — this update only applies to provider servers.”

It’s pretty common for Apple to come up with relatively short term notices like these. Unfortunately, they also frequently lack any further technical documentation.

Based on discussions I’ve had with various other iOS devs during the last few days, I sense that there might be a little bit of confusion as to what exactly this announcement means.

Typical questions, I’ve seen:

• Do we have to recreate our certificates or .pem files?
• Do we have to install any additional certificate on our servers?
• We never installed anything else than the production and sandbox .pem files as outline in Apple’s documentation. Do we now have to install a third certificate and change our existing backend code?

Over at GrandCentrix, Germany’s largest iOS development shop, we use our own Rails based Push Notification provider service hosted with Engine Yard and deployed through Amazon EC2 instances.

We never installed anything else than two .pem files. We created those with Mac OS X Snow Leopard’s Keychain Utility, exported key and certificate as .p12 files and finally converted them to .pem files using OpenSSL from the command line.

We never downloaded any additional certificates from Entrust’s website, nor did we install any special third party stuff into our local keychains.

I’ve contacted Apple and received some clarifying statements. I thought sharing them with other iOS devs might shed some light on the topic.

In a nutshell you most likely don’t have to do anything!

If you’re hosting your Push Notification service on a Linux box, any SSL connection is very likely already using Entrust’s certificate, even though you never manually installed it.

You can easily check this by using the Sandbox environment, which has already been switched to the higher security mode in March 2010. Bottom line: If your service successfully sends out APNs via Apple’s Sandbox servers today, you’ve got everything in place.

A little bit of background

Take a quick look into the /etc/ssl/certs folder. The point is: Most Linux distributions come with the required certificates preinstalled. That is, why you never had to manually install anything but got Push Notification services working anyway.

Here is an excerpt of the information that I’ve received from Apple:

“This announcement does not involve the certificate you receive from the Provisioning Portal. You do not need to generate a new Production or Sandbox certificate from the Provisioning Portal. Your existing PEM file should continue to work just fine.

This announcement is regarding other certificates (involved after your Provisioning Profile certificate is used to connect) to further validate the connection. Depending on the version of your Operating System and push technology stack, these certificates may already be installed and you didn’t even know they were being used.

The location of these certificates will be dependent on the operating system and push technology you are using. Mac OS X for example, keeps all of its certificates in the Keychain where many of the built-in scripting languages such as PHP, Ruby, Perl, etc. will automatically find the appropriate certificate. Other operating systems and or languages may have specific installation paths. If you determine that you need the new 2048 certificate, check the docs for the appropriate installation location specific to your implementation.

If the server & technology you are using to push to the APNS Sandbox environment is the same as that in your Production environment, then you most likley already have the appropriate certificate since it was probably included in the standard installation of the operating system or push technology stack.  Perhaps the simplest test you can perform is to test in the APNS Sandbox environment then make sure that the Entrust certificates in your Production environment match those in your Test environment.”

And:

“When you connect to APNs to send notifications, that connection is a secure TLS/SSL connection. Part of the TLS/SSL protocol is the handshake where the system you’re connecting to sends its digital certificate to the TLS/SSL protocol software on your system (commonly OpenSSL or SecureTransport on Mac OS X systems). If you specify in your TLS/SSL options that you want to validate the connection to APNs, the TLS/SSL software on your system will check that the certificate was signed by a trusted certificate authority (CA). In the OpenSSL case, the verify_peer and cafile options are set in the stream_context.

With APNs, Entrust is the CA, so the APNs server certificate needs to be checked against the proper Entrust root certificate. There is a different root certificate for validating certificates with a 2048-bit public key vs. a 1024-bit public key, which is why the notice was sent out.

In the OpenSSL case, you’d add the new root certificate to the .pem file you specify in the cafile option. You can add that certificate at any time because all root certs in the cafile will be considered when the APNs certificate is validated.

The sandbox environment has been using a 2048-bit certificate since March, so you can test things in the sandbox to make sure you have the new root certificate installed properly.”

Hope this helps.