At my organization, I'm responsible for the provider service that sends push notifications to mobile devices.
As you will already know if you are searching for this topic, Apple has the Apple Push Notification Service: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/Introduction.html and Google has the Google Cloud Messaging https://developers.google.com/cloud-messaging/gcm frameworks to send notification to devices. In fact, GCM now offers sending notifications to APNS, but for those of us whose applications predate that GCM feature, we have to keep APNS certificates up to date on our provider servers for sending push notifications through APNS (and I'm guessing you have to plug in the APNS certificate to GCM if you want google to send notifications to apple).
So how do you create an APNS certificate in the first place?
On this topic, Apple does have some documentation. https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/AddingCapabilities/AddingCapabilities.html#//apple_ref/doc/uid/TP40012582-CH26-SW11
So when you first create an App, it's pretty straightforward as to how to get the certificates.
In our case, we use password protected .p12 files for certificates. So you have to install the certificates in a Mac keychain, then select the private key under the certificate, and right click and export to create a password protected .p12 file that works for push notifications.
What happens when it's time to renew the certificate?
Renewing a certificate is a scary part because we have so many questions around it.
Overlapping certificates:
Let me right away put this question to rest. Yes, we can have overlapping certificates with different validity windows. On the Apple developer portal (as described in the link above about creating the original certificate), under each application that you have, there will be two certificates listed (assuming you're already using push notifications). These are the Development and the Production certificates.
Next to each, you have the option to create new certificates. It looks like you cannot have more than 3 active certificates, or apple limits how many times you can create new certificates within a time window - there is some such restriction as we observed empirically. We did not play around enough to clearly understand what are the restrictions. However, within that limit, you can have overlapping certificates.
And obviously, since you can have two certificates with some overlap in validity, you do not have to worry about incurring a downtime when swapping certificates.
What really is the purpose of this certificate?
The only purpose that the certificate serves is to authenticate the SSL connection between your provider service and the APNS endpoint for this particular application. The certificate is not in any way connected to your provisioning profile.
So that means, there is no direct connection between application and the certificate. An app published while an old certificate is in effect will still receive notifications sent to APNS using a new certificate.
Creating New Certificate:
I already linked the Apple documentation on creating a new certificate. For renewal, the process you follow is the same, except you leave the old certificate as it is there (do not revoke it) and just create a new certificate alongside it. So now you will have two certificates listed under the Development/Production/both section for your application; one which already was there, and the other - the newly created certificate.
So that means, there are now two active certificates. And as long as you created the new one before the old one expired, you have a period of overlap.
During that period of overlap, push notifications can be sent with either of the certificates. This give you a window of time to switch certificates on your provider server without having to incur a downtime. The only downtime you will incur is if you need to bring down the service to change the certificates - in which case it's a design problem in your provider service and not Apple's fault.
A few words on CSRs:
What is a Certificate Signing Request?
It actually is a file containing a pair of public and private keys. When you plug a CSR into apple to create your certificate, that key pair goes into the certificate.
That also means, once a certificate is created, the CSR can safely be discarded (and it probably is better to discard that keep it around so you don't have your keys lying around).
So that should also allay any concern around your no longer having the CSR you used to create your original certificate. It is just right that you didn't keep the CSR around.
Can I reuse a CSR?
If you are responsible for multiple IOS applications, your developer account will have them all listed. For human sanity it is likely you have at some point while developing, revoked all your certificates and recreated them on the same date, so that they all expire at the same time.
So now, when the certificate renewal time comes around, it is tempting to create one CSR and use the same to renew all your certificates. DO NOT DO THIS.
If you reuse the same CSR for multiple IOS applications, only the first application will work correctly.
We actually tested this out to some degree. We created a CSR and created two certificates with it, one for App A and one for App B. We were able to send push notifications to App A using App A's certificate. However, we were not able to send push notifications to App B using App B's certificate.
In addition, we were actually able to use App B's certificate and send push notifications to App A. This makes sense because the CSR had a key pair that is now associated with App A. Both certificates contain that key pair; so you are able to send to App A using either of these certificates.
Conclusion:
I hope this anecdotal recitation of my experience helped you understand the push notification certificate renewal process. If you have additional questions, please feel free to comment on this post, and I'll try best to answer them.
.
As you will already know if you are searching for this topic, Apple has the Apple Push Notification Service: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/Introduction.html and Google has the Google Cloud Messaging https://developers.google.com/cloud-messaging/gcm frameworks to send notification to devices. In fact, GCM now offers sending notifications to APNS, but for those of us whose applications predate that GCM feature, we have to keep APNS certificates up to date on our provider servers for sending push notifications through APNS (and I'm guessing you have to plug in the APNS certificate to GCM if you want google to send notifications to apple).
So how do you create an APNS certificate in the first place?
On this topic, Apple does have some documentation. https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/AddingCapabilities/AddingCapabilities.html#//apple_ref/doc/uid/TP40012582-CH26-SW11
So when you first create an App, it's pretty straightforward as to how to get the certificates.
In our case, we use password protected .p12 files for certificates. So you have to install the certificates in a Mac keychain, then select the private key under the certificate, and right click and export to create a password protected .p12 file that works for push notifications.
What happens when it's time to renew the certificate?
Renewing a certificate is a scary part because we have so many questions around it.
- Will I incur downtime for notifications while I renew?
- Will pre-existing users of my app lose notification functionality, and need to reinstall the app since the certificate is renewed?
- Can I have an overlapping time window where multiple certificates are valid so I can transition?
- Do I have to republish the app on the App Store?
- I have lost he Certificate Signing Request I originally used; is this a problem?
Overlapping certificates:
Let me right away put this question to rest. Yes, we can have overlapping certificates with different validity windows. On the Apple developer portal (as described in the link above about creating the original certificate), under each application that you have, there will be two certificates listed (assuming you're already using push notifications). These are the Development and the Production certificates.
Next to each, you have the option to create new certificates. It looks like you cannot have more than 3 active certificates, or apple limits how many times you can create new certificates within a time window - there is some such restriction as we observed empirically. We did not play around enough to clearly understand what are the restrictions. However, within that limit, you can have overlapping certificates.
And obviously, since you can have two certificates with some overlap in validity, you do not have to worry about incurring a downtime when swapping certificates.
What really is the purpose of this certificate?
The only purpose that the certificate serves is to authenticate the SSL connection between your provider service and the APNS endpoint for this particular application. The certificate is not in any way connected to your provisioning profile.
So that means, there is no direct connection between application and the certificate. An app published while an old certificate is in effect will still receive notifications sent to APNS using a new certificate.
Creating New Certificate:
I already linked the Apple documentation on creating a new certificate. For renewal, the process you follow is the same, except you leave the old certificate as it is there (do not revoke it) and just create a new certificate alongside it. So now you will have two certificates listed under the Development/Production/both section for your application; one which already was there, and the other - the newly created certificate.
So that means, there are now two active certificates. And as long as you created the new one before the old one expired, you have a period of overlap.
During that period of overlap, push notifications can be sent with either of the certificates. This give you a window of time to switch certificates on your provider server without having to incur a downtime. The only downtime you will incur is if you need to bring down the service to change the certificates - in which case it's a design problem in your provider service and not Apple's fault.
A few words on CSRs:
What is a Certificate Signing Request?
It actually is a file containing a pair of public and private keys. When you plug a CSR into apple to create your certificate, that key pair goes into the certificate.
That also means, once a certificate is created, the CSR can safely be discarded (and it probably is better to discard that keep it around so you don't have your keys lying around).
So that should also allay any concern around your no longer having the CSR you used to create your original certificate. It is just right that you didn't keep the CSR around.
Can I reuse a CSR?
If you are responsible for multiple IOS applications, your developer account will have them all listed. For human sanity it is likely you have at some point while developing, revoked all your certificates and recreated them on the same date, so that they all expire at the same time.
So now, when the certificate renewal time comes around, it is tempting to create one CSR and use the same to renew all your certificates. DO NOT DO THIS.
If you reuse the same CSR for multiple IOS applications, only the first application will work correctly.
We actually tested this out to some degree. We created a CSR and created two certificates with it, one for App A and one for App B. We were able to send push notifications to App A using App A's certificate. However, we were not able to send push notifications to App B using App B's certificate.
In addition, we were actually able to use App B's certificate and send push notifications to App A. This makes sense because the CSR had a key pair that is now associated with App A. Both certificates contain that key pair; so you are able to send to App A using either of these certificates.
Conclusion:
I hope this anecdotal recitation of my experience helped you understand the push notification certificate renewal process. If you have additional questions, please feel free to comment on this post, and I'll try best to answer them.
.
No comments:
Post a Comment