We have implemented Over The Air (OTA) profile delivery with 3 phases :
Phase 1 : Authentication
Phase 2 : Certificate enrollment. A new certificate is sent to device and replaces Apple certificate
Phase 3 : Device configuration. Device response is signed with the new certificate and server responds with a config file.
The first delivery works fine.
We try to deliver a second configuration profile with the same device : iPhone 6 plus iOS 8.1.1
In reading Apple documentation, Phase 2 should be called by the device only the first time.
For the second delivery, "if the device has been registered previously and is merely requesting a new configuration, it signs the request with the certificate previously provided by the CA" (Apple documentation).
But for the second delivery, device response is still signed with Apple certificate and not with the certificate sent in the first Phase 2.
Do you know why the device still uses the Apple certificate and not the certificate previously got in Phase 2 for a new configuration ?
Thanks for your help.
To be honest, one time i implemented this we didn't much care about signature from the device side. We verified the challenge was correct before issuing the cert and then encrypted profile with the public key of the cert we sent. If the device was not the same it would be unable to read our target profile, ensuring the security of the delivery.
Related
I have 3 apps in Appstore with different production certificate, Is there any possibility to have those three apps with single production cerlificatae.
To clarify on the previous answer, you can sign all your app store apps with a single iOS Distribution certificate. You will need to create 3 separate Distribution provisioning profiles, all tied to the same certificate, but each assigned to the Application ID for their specific app. If you have an existing app store distribution certificate, you can simply use it when creating your new provisioning profiles - simply check the box next to your certificate when you create or edit the profile.
So you will have one cert (e.g. App Store Cert), and three profiles like this:
App One:
App One Provisioning Profile (App Store Distribution)
Cert: App Store Cert
App Id: com.example.appOne
App Two:
App Two Provisioning Profile (App Store Distribution)
Cert: App Store Cert
App Id: com.example.appTwo
App Three
App Three Provisioning Profile (App Store Distribution)
Cert: App Store Cert
App Id: com.example.appThree
Unless something has changed, I do not believe Apple will even allow you to have more than 2 active Distribution certificates at any given time. They allow two only so that you can create a second when your current cert is about to expire. This gives you time to ensure all your developer have the new cert prior to the old expiring, but the old will still work in the transition.
You need to have different profiles for each application. Else certificate does not matter in terms of number i.e., you can have same certificate for multiple apps only catch is you need to have different provisioning profiles for each application.
API GET call from a website only from mozilla browser I get following error "VIP uses invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates. An additional root certificate may need to be imported”
tested the vip thru SLLLABS.com found out that cipher suite returned from my certificate from server is not in the preference list of mozilla - https://www.ssllabs.com/ssltest/viewClient.html?name=Firefox&version=47&platform=Win%207&key=132
Is this could be the issue ? How to add the required cipher suite in the certificate, what steps to follow.
Report also indicated there is no forward secrecy and session cahcing, not sure if this causes this issue?!
SSL Lab report.
Firefox 31.3.0 ESR / Win 7 Server closed connection
Firefox 46 / Win 7 R Server closed connection
Firefox 47 / Win 7 R Server closed connection
Forward Secrecy No WEAK (more info)
Session resumption (caching) No (IDs assigned but not accepted)
cipher suite returned from my certificate from server is not in the preference list of mozilla - Is this could be the issue ?
No. Your error message is specifically:
"The certificate is not trusted because the issuer certificate is unknown. The server might not be sending the appropriate intermediate certificates. An additional root certificate may need to be imported"
This specific issue is that Firefox can't build a chain back to a trusted root. Firefox uses its own root store and root program, so it differs in behavior of IE / Edge / Chrome, all of which use the Windows certificate store or OS X certificate store.
Without knowing exactly which CA issued your certificate, and what intermediates your server is set to serve, it's hard to say exactly what is wrong.
If SSL Labs says the certificate is fine, look for "incomplete chain" or "extra downloads" in orange where it displays the certificate chain. If those show, then you have an incomplete chain, which are necessary to building back to the root.
If SSL labs says your certificate isn't trusted (shows a big red 'T') then your certificate is not issued by a public CA, or SSL Labs wasn't able to find the intermediates, either.
Report also indicated there is no forward secrecy and session cahcing, not sure if this causes this issue?!
Forward secrecy is a very good thing to have enabled but it is not the cause of this error.
In development everything works fine:
my app (built with Phonegap) sends the device token to the server
my server sends the notification to the Apple servers
I receive the notification on my iPhone
But, when I switched to production (enabled push notifications and created a new SSL certificate for production) I keep getting "(8) Invalid token" from Rapns (which is installed on my push notification server).
I have read that this message is probably caused because I use a development device token in production (i.e. my server use a production certificate, but the app is running in development and sends a development device token to the server).
How can I run the app in production mode, so that I get a valid device token for production?
I think I should use an Ad Hoc Distribution Provisioning profile, but even if I have changed the "Code Signing Identity" properly in Build settings, I still get the same token I was getting in development! And this obviously doesn't work.
Solved by creating an archive - instead of run - and signing it with an Ad Hoc Distribution Provisioning profile.
You may have to delete the already installed application on the device - do a xcode clean up(for a safer side) - reinstall the application.
So as many of my past questions indicate I've been working on implementing an Apple MDM service from scratch. It now works flawlessly with pretty much any iOS device we throw at it, which is nice. However when we try to enroll an OS X device, which according to Apple uses the same API, it fails miserably with an unexpected error (as apposed to excepted ones I assume).
The following 2 lines show up in the system.log:
Mar 18 15:33:05 dizzy mdmclient[23234]: *** ERROR *** [Agent:510] ProcessOTABootstrapPayload (Unable to receive OTA identity profile <InternalError:1>)
Mar 18 15:33:05 dizzy System Preferences[93537]: *** ERROR *** [CPInstallerUI:510] Profile installation (Device Enrollment (com.capasystems.enrollment.handshake )) (Unable to receive OTA identity profile <InternalError:1>
Looking through the SCEP servers logs I can see it doesn't even try to connect, before determining it can't recieve the OTA Identity profile. So I'm kind of at a loss here, I've tried troubleshooting network issues, but an iOS device on the same network works fine. I've tried using an SSL connection and a non-SSL connection. No difference.
We are using JSCEP for the SCEP server if it makes any difference. Does anyone have the faintest idea what undocumented extra infrastructure or otherwise I'm missing in order to get the whole MDM thing working on OS X?
I was having the same issue for a long time, I spent waaay too much time trying to figure this out.
For me, the answer came when I was able to successfully enroll one machine (my macbook pro, my personal machine), and unable to enroll another (a mac mini). Turns out, to enroll successfully, a valid certificate with CN=com.apple.idms.appleid.prd.XXX... is required. This certificate appears to be linked to the logged in user's iCloud account, which means if you're not logged in to an iCloud account on the machine, you don't have the certificate. After I (a) logged in to a valid iCloud account and (b) attempted to enroll in our mdm solution, this certificate showed up in the login keychain and the enrollment finished smoothly.
Hope this helps someone.
I would double check network problems. You Mac and your iPhone can be on two different networks (wired and wireless) and in such case they can have different ports accessible on SCEP server.
Also, in the case, if your SCEP server is ssl protected (as example sitting behind Apache), make sure that your Mac has root certificate installed in System Roots.
BTW. If you have something like Apache sitting upfront of SCEP server, check it logs too.
The error means the device is unable to retrieve the identity cert in the payload.. either point the identitycertuuid to scep payloaduuid or to the identity.p12 payloaduuid that you are including with the payload.
Question: How can I securely include the SSL cert required for push notifications in the installer for my server product?
Background: Apple Push Notifications require a client SSL cert to be in place on the server that's making the calls to Apple.
My product has a traditional client/server architecture, i.e. a customer installs the server within their intranet and then obtains the iOS client from the App Store and connects the client to their instance of the server.
The point here is that the customer installs the server themselves, rather than a cloud architecture where I would manage the server myself.
My problem is that I don't know how to package the push notification certificate in the server installer in a secure way. I can't distribute the .p12 file without a password because that would expose my private key, and I can't use a password because the password would have to be included somewhere else in the installer which would defeat the purpose. Do I need to relay messages from all of my customers through a server that I manage, which has the SSL client cert? Do I need to install the SSL cert by hand into every one of my customers' sites?
Surely others must have run into this problem already? Or has everyone moved to the cloud?
Here is a major observation that happened to me over the weekend regarding Apple Push certificates. While there many references out there to setting up the Apple Push server side certificates, here is a MAJOR point I discovered that I cannot find referenced in any Apple documentation, or via google.
My situation: I have Push Certificates (sandbox) working great on Windows Server. Now it is time for production. Installation of production certs is successful like many times before. However, while the production push transmission completes error free, no pushes are generated to the device. Hmmm.
I just HAPPEN to notice that my Mac's time is roughly a minute off from the Windows Server (command-tabbing between MacOS and VM-Ware). Looking at Windows and Mac Settings, I see Windows internet time is set for "time.windows.com", and the mac for "time.apple.com". Just for kicks, I change the windows server time to "time.apple.com". Instantly, pushes are now being sent to the device. Nice. :-)
I dodged a major bullet here, this would have probably driven me insane trying to figure this one out. I do not claim to be an SSL cert guru... I (like most every one) just want to get this stuff to work because we have bigger fishes to fry.
I hope this is useful information.
I know only the solutions to install certificates for push notifications :
.p12, the password is in the code of the sending
.cer (.p12+private key) the password is requested at the importing of the certificate.
In the first case, you can deploy your solution, and download some code, for example xml with the password.