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.
Related
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 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.
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.
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.