I am using APNS Certificate & VOIP Services Certificate in parallel in my iOS apps, I have created APNS (both Sandbox & Production), then uses AWS SNS as an intermediate and then creates application ARN and endpoints at SNS and send push from my server via SNS (with the corresponding certificates), these steps work fine for APNS, Push notifications are working fine.
But when I go to VOIP, I am able to get the app working fine in my test server (that is I am getting VOIP notification when using test server), but in case of production, it's not working...
FYI
Am using two different tokens for both APNS & VOIP
Have created & rechecked the VOIP certificates(single certificate for both test & production)
Am not getting any idea of whats wrong... TIA... Requesting for suggestions or anyone faced the same issue?
It sounds like you did everything correct.
What I can recommend as an alternative solution is to create a single Universal APNS certificate which works everywhere - for Production/Sandbox standard pushes + VoIP Production/Sandbox
And use this single certificate for both cases
Here is a very simple guide I used to generate single Universal certificate which works everywhere https://developers.connectycube.com/ios/how-to-create-apns-certificate
You have to check the endpoint for the APNS. So when you are working in dev environment you should send in APNS_ENDPOINT: api.development.push.apple.com and when in production in APNS_ENDPOINT: api.push.apple.com
Related
I'm currently learning to develop for iOS and reached the points where i want to play around with some push-notifications.
I was able to use the developing certificate to register the iPhone for Push-Notifications but now i want to establish a connection between my debian rootserver and the APNS (for the first try i'll connect to the sandbox-server).
Some tutorials showed me how to receive a certificate for my Mac but therefore I need a valid certificate for my server or am I wrong with this assumption?
As far as I know the APNS works with apple certificates only. In short:
Create an app id in provisioning portal
Enable it for push notifications
Generate certificates following the usual procedure.
Combine the generated certificate and private key into one .pem and us it in communicating with apple.
This tutorial was all I needed:
http://www.raywenderlich.com/3443/
I have some questions about apns in my own server-side application. I have a java application who should be able to send push notifications to apple.
The server and also the iphone app is working, my question aims to the distribution of the server application and the certificates.
Can I distribute all servers to the users with the same certificate? Or do I have to send every user their own certificate for their server?
Every server should be able to send their push messages to the apple servers for delivery, like:
Server-Application <--> Apple Push Notification Server <--> iPhone / iPad etc...
Is that possible?
Every server should be configure with certificate and should have SEND notification LOGIC coded in JAVA or any other language like PHP or C#.
You need one Certificate for every Server.
Every server should be preconfigure for APNS requirements. You need to build server with certificate and port enabled on that. Please check Ray wander linch' guide for APNS and you will find what it takes to do above.
I am little confused about the MDM, wish that someone could help me here. I have studied the docs from the Apple website regarding the iOS MDM,but still I feel puzzled ,I have some questions.
Whether MDM server is communicating APNS every-time when it needs to execute command ?
Is it very complex to setup our own MDM server and how to setup our own MDM server ?
Thank you in advance.
1) the general idea is that you send one request via APNS and then respond with a command when the device 'phones home' to your MDM server. Once the device responds to your command, you can send another command back in response and so on until the device has executed all the commands at which point your server should respond with an empty HTTP response.
2) That entirely depends on what your definition of complex is! I have created 2 MDM 'servers' in the past year and it's not impossible but quite complex to detail.
MDM server communicates only when it needs to send a command to the device.
Here is how it goes,
MDM server contacts APNS server with MDM payload.
APNS server triggers a wake up on device to check server for MDM command.
Mobile device contacts the MDM server for command to be executed.
Implementing MDM is simple if you have a enterprise account.
Get your MDM certificate.
http://www.blueboxmoon.com/wordpress/?p=877
Using IPCU create a profile and push it on mobile.
With this the device push magic will be passed to the checkin URL you specified in the config profile.
Then trigger the mdm payload using JAVAPNS with push magic and token.
JavaPNS - https://code.google.com/p/javapns/
Create a simple page that will respond to device command.
Refer Blackhat guide for full documentation.
https://media.blackhat.com/bh-us-11/Schuetz/BH_US_11_Schuetz_InsideAppleMDM_WP.pdf
or this http://darthnull.org/media/papers/MDM_CommandReference.pdf for commands reference.
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.
Can any body explain what is this and what changes we need to make on Server/ iPhone app?
This will not affect anything on your side (as far as your SSL library supports 2048-bit keys/signatures, nearly all modern SSL client libraries do that).
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.