Our production push ssl certificate is going to expire soon. If I generate a new certificate, will the other certificate remain valid until it is set to expire (at which point it must be replaced with the new certificate)?
Will both certificates work at the same time?
Just concerned about the timing. For our app, we host a push server and so do a few of our customers. I want to make sure creating a new certificate and updating our push server with the new certificate doesn't mess up our customers' push servers that will, for a time, still have the old certificate installed.
It seems like you don't invalidate the old certificate...
"You can generate a new certificate without revoking the old one, and
use them simultaneously to ensure they are working before revoking the
old one."
At least according to this post
Related
I am implementing a push notification system for one of my apps, so I am following this tutorial and generating a SSL certificate for that.
This app of mine involves also, some exchange of data between the app and the server and I would like it to be SSL protected and I was wondering of getting a SSL certificate from verisign or other company like that.
My question is: is this SSL certificate created for push a regular SSL certificate, so in that can use it also to establish a https connection to the server (and save a couple hundred dollars to order a third party certificate)? I don't know much about SSL certificates, but I hope it can be used for that...
This will be amazing!
Since each certificate is tied to a specific domain, I'm not sure how this would work. There is a concept of wildcard certificates, but I still think they have to be for the same domain.
In your case, it sounds like you will have the Apple push certificate, which validates the connection between your server and Apple's push notification server. The other certificate would be to validate/secure the connection between your iOS app and your server. Both of these are assigned a different domain (gateway.sandbox.push.apple.com vs. yourserver.com).
One option you do have depending on how your iOS app is structured is to use a self-signed certificate between your iOS app and your server. I'm guessing the end-user will not be seeing the certificate anyway. This might be a way to save you money before deciding on a third party certificate.
I am new to the APNS certificate thing. My question is a old developer lost our Private Key which we used for several in-house (ad-hoc) applications, and an application we use to push out applications and policies to users. I know that the only way to get the private key is to revoke the certificate and then generate a new one and re-sign all the internal applications and re-deploy with the new cert. My only concern is what happens to the application that uses APNS, does this still use the distribution certificate from our apple account, or will this not be affected when we revoke the distribution certificate?
The push certificate is not part of the provisioning profile. It has nothing to do with the client (the app), only your server's connection to APNS is affected.
I've visited http://msdn.microsoft.com/en-us/library/ff369721.aspx and it is strongly implied that if you need to renew your code signing certificate, then you will need to re-sign your application and re-publish it. There is no change that happens to the certificate from the side of the CA that extends the lifetime of the certificate. Is this correct?
There is no change that happens to the certificate from the side of the CA that
extends the lifetime of the certificate. Is this correct?
No.
The validity dates are included in the certificate, so a certificate with a new expiration date is different than your currently expiring one.
We have deployed our application with push notifications using a development provision profile. The APNS SSL certificate expires from 3 months , so my client wants to extend it's valid period preferably by several years. Is it possible to get a 3rd Party SSL certificate to connect to APNS ?
No, it is not possible. You must generate the certificate through the iOS Provisioning Profile. By the way, you need to deploy your application using a production certificate and not a development certificate.
We had no problem sending notifications to provisioned devices using the development certification and gateway.sandbox.push.apple.com. But now now that our app is in the store, it appears we can't even connect to the production apn server (gateway.push.apple.com) to send pushes, even when we're using the machines that created the certificates in the first place.
We've run this through PushMeBaby and it looks like the connection to gateway.push.apple.com is getting refused. When it executes the handshake ( SSLHandshake(context) ) the result is error code -9044, or errSSLConnectionRefused - The peer dropped the connection before responding.
I know enough about ssl and encryption to know that I don't know a thing, but I'm pretty sure that the issue is (or starts with) our production SSL cert. Push notification is enabled for production in the iPhone portal (we have a green light). The certificate has been installed on the machine running PushMeBaby and I see both the certificate and the signing key in my keychain. When I exported the development push certificate and used it in PushMeBaby, I was able to connect (and send pushes) no problem. But with the production cert, We get nowhere. We've repeatedly revoked and recreated both the dev cert and the prod cert on two separate computers, so if this is human error, we're doing it repeatedly.
One thing that may be a factor is that I have the "team agent" key on my keychain, but I'm not her. I can and have submitted binaries to the App store without any issue.
Also, we've not set up a provisioning profile after creating the production cert. I'm not sure if that's a factor, but I can't see how it might be for an in-store app.
I sure hope someone has some ideas, because I'm out of them!
As the documentation said it exists 2 certificates and 2 IP address for the push notification:
Sandbox: gateway.sandbox.push.apple.com, port 2195. (for the development)
Production: gateway.push.apple.com, port 2195. (for the release)
You always use the gateway for the development. Try to use the other gateway (for the production).
For more information see here: Provisioning and Development
Yes, I've solved this error.
I lost a few days finding the solution.
The problem is in the line:
result = SSLSetPeerDomainName(context, "gateway.sandbox.push.apple.com", 30);
NSLog(#"SSLSetPeerDomainName(): %d", result);
You have to change the port to number 30. This solves the problem.
Similar problem was happening in our tests because we were trying to use developer device token instead of a production one.