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.
Related
I am getting ERR_CERT_REVOKED in iPhone while accessing our website which uses a GoDaddy SSL certificate. It works fine on Laptop on all browsers but gives this error on iPhone.
Godaddy is facing an AutoSSL technical issue where they are not able to renew the SSL certificate. Mine has been down for 2 days now and has contacted their support multiple times. No permanent fix as of now.
You can do these steps which can put you in the queue for AutoSSL renewal. They haven't mentioned a timeframe for the resolution of this issue, unfortunately.
Steps:
Go to Cpanel of Hosting
Select SSL/TLS
Select Generate, view, upload, or delete SSL certificates.
Delete all self-signed certificates
Go to Cpanel and select SSL/TLS Status
Select all domains you want to renew and click Run AutoSSL
This will put your domain in the queue for renewal.
God knows when these guys will resolve the issue and renew it though.
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
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 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.
My Apple Notification sometime received some get failed to reach on device.
Please help me and tell different scenarios when an Apple Notification fails.
Any help would be very appreciated.
There could be various reasons for push notification not working. This check list can help you find few :
APNS CheckList
Provider should install the Entrust Secure Server CA root certificate. This allows TLS/SSL to verify the full APNs server cert chain. This root certificate can be downloaded from Entrust's site.
The device token from development environment will not work on production push service. Each pushenvironment will issue a different token for the same device. If an invalid device token is sent to the wrong environment, the push service will see that as an invalid token and discard the notification.
If you remove your app from your device and then send a push notification to it, you would expect to have the device token rejected, and the invalidated device token should appear on the feedback service. However, if this was the last push-enabled app on the device, it will not show up in the feedback service. This is because deleting the last app tears down the persistent connection to the push service before the notice of the deletion can be sent.
Push providers are often behind firewalls. To send notifications, you will need to have TCP port 2195 open. To reach the feedback service, you will need to have TCP port 2196 open. Devices connecting to the push service over Wi-Fi will need to have TCP port 5223 open.
The IP address range for the push service is subject to change; the expectation is that providers will connect by hostname rather than IP address. However, the entire 17.0.0.0/8 address block is assigned to Apple, so you can specify that range in your firewall rules.
We can enable APNS logging, install the configuration profile APNsLogging.mobileconfig on device by either putting the file on a web server and downloading it location using Safari on your device, or by sending it as an email attachment and opening the attachment in Mail on your device. We can use mdm to push profile.
More details can be found here
Apple explicitly states that notifications are not guaranteed. They can fail for all sorts of reasons. For example, if you send more than one notification to a device before the first one has been delivered, the prior ones are deleted. I seem to remember reading in the documentation somewhere that the sandbox environment occasionally fails to deliver a message so that you can test your failure code.