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.
Related
I have company provided Samsung S20. I have successfully installed Microsoft's Intune Company Portal App.
Then I was also able to register company portal. However after connecting to company portal, it suppose to download certificate from the company portal. But its not downloading any certificate or i dont see any notifications that it is downloaded.
Once i have the certificate, i will use it to connect to Access Point. But that's next step after i have the certificate.
1>What could be the potential issue for not downloading certificate?
2>Where and how can i view the logs?
3>In Company Portal App, Under settings i see Diagnostic Data-> Copy logs. Which says Copy logs to SD card. Where does it actually copies logs.
4>I am connecting from home. Is there any settings i need to do on router.
Note that, I also have company provided iPhone. and I was able to install and configure everything without any issue.
1>What could be the potential issue for not downloading certificate?
It depends on what you need the certificate for. How are you issuing the certificate to the device? via configuration policy?
2>Where and how can i view the logs?
Plug the device into a computer and allow USB to transfer data and files. Should be under Android\Com.microsoftintunecompanyportal\data
3>In Company Portal App, Under settings i see Diagnostic Data-> Copy logs. Which says Copy logs to SD card. Where does it actually copies logs.
refer to previous answer
4>I am connecting from home. Is there any settings i need to do on router.
Sounds like you're trying to get a trust certificate on the device but I would need to understand more about what you're trying to do. RIght now I'm working on a wifi profile for android devices and am using SCEP certificates to do that. But you're welcome to read this to try to gain a better understanding.
https://learn.microsoft.com/en-us/mem/intune/protect/certificates-configure
I have an application that receives items from a high-speed scanner device. As the items are received, they are written to disk using SQL Compact. The following digitally signed Microsoft DLLs are used:
sqlceca40.dll
sqlcecompact40.dll
sqlceer40EN.dll
sqlceme40.dll
sqlceoledb40.dll
sqlceqp40.dll
sqlcese40.dll
I recieved a performance complain from a customer, and traced the issue using Microsoft Procmon to a TCP Reconnect failure when attempting to contact the site for certificate validation when we make calls to methods in these dlls. At first, I could not recreate the issue locally. After talking to their infrastructure people and developers, I learned that they must use a proxy for internet connectivity. Some of the customer's users (in the test environment) had valid proxy settings, and they got good performance from our application. Naturally when they turned their proxy settings off, the validation could not be done and the performance issue arose.
I attempted to recreate the issue by setting our machine up with false proxy settings to a non-existent machine. On my initial attempt, I still got good performacne from our application, and no attempt was made to contact the internet for cert validation. After looking at the cert's validation chain, I noticed that it derived from the certificate "Microsoft Root Certificate Authority". I then exported and deleted that Cert, and was able to reproduce the issue as determined by a comparison of logs.
I did the following tests:
Test 1:
1. Opened the proxy settings, and enabled them pointing to a non-existent address.
2. Ran a test.
Results: No performance issue.
Test 2:
1. Exported the “Microsoft Root Certificate Authority” cert and moved it to the untrusted folder.
2. Ran a test.
Results: The performance issue occurred.
Test 3:
1. Deleted the “Microsoft Root Certificate Authority” cert.
2. Started a test.
Results: The performance issue began occuring.
3. While the test was in progress and device was hesitating I removed the false proxy settings.
Results: The performance issue disappeared and the application recovered.
Tentative Conclusions:
1. That I can simulate the no internet access condition by providing false proxy settings.
2. If the “Microsoft Root Certificate Authority” cert is installed properly, the .Net infrastructure does not need to access the network to verify the necessary cert.
3. If not, it will attempt to validate via the internet connection.
Nevertheless, when the customer checked the certificates in the "Trusted Roots Certificates" folder of mmc->certificates-local computer. The "Microsoft Root Certificate Authority" certificate does appear there, and it seems to be identical to mine. Yet for some reason the use of the dll's causes certificate validation to attempt to access the internet resulting in a performance issue.
In the customer's situation, eventually devices will be used in production with no internet access.
My question is, is there a setting (registry, or GPO) that might cause certificate validation to always attempt to use the internet, regardless of whether the root certificate of the validation chain is installed in the local computer?
Can a setting be enabled that causes a certificate validation to access the internet to check to see if the root certificate has been revoked, for example?
Please feel free to ask questions if you need more information.
This appears to occur for SQL Server Compact 4.0 on any system with an invalid proxy configuration, as a Certificate Revocation List check is run each time the engine is loaded (which happens on the first call to .Open()).
Solution: To avoid this delay, which probably affects any signed app on the system in question, you must fix the configuration or disable the check. The check can be disabled via UI or via registry settings, as described here: http://digital.ni.com/public.nsf/allkb/18E25101F0839C6286256F960061B282
For additionla issues see my blog post here: http://erikej.blogspot.com/2013/08/faq-why-is-opening-my-sql-server.html
We have an existing certificate (global sign) that works fine when a Windows Mobile application (.NET 3.5) tried to consume the web service (also written in .NET 3.5) that is hosted on IIS.
However the when we make the re-issued certificate (global sign) live, the Windows Mobile application is failing to connect to the web service, the error we are getting is "Could not establish trust relationship with remote server". Ive tried searching for this on Google many times and have not found a suitable fix.
We have also tried to copy (and install) the ROOT and intermediate certificate in the chain to the device, but this still does not work.
When we test the new certificate with a PC web browser (IE, Firefox, Opera), a Desktop application that consumes the web service (.NET 3.5), and even Internet Explorer on the Windows Mobile device the .NET web service definitions/documentation page is show without problems (no warnings, or errors), it seems to only be an issue on the windows mobile device when using a compact framework (3.5) application is trying to consume the web service.
We have validated that the certificate is installed correctly on the SSL shopper site, and after our google searches we came across and implemented (as a test) a "trust all" ICertificatePolicy handler, this has resolved the problem, however i was hoping that this problem could be addressed by configuration/setup change rather than a code change and a re-deployment of over 150 windows mobile based devices.
The ICertificatePolicy hander did show up the error that was being returned when trying to validate the certificate: the problem parameter was set to: -2146762481 (0x800B010F in HEX), which i believe is the "CN No MATCH" error, however Ive searched for this in both its numeric, hex and name form and have yet to find a resolution other than the "Trust all" code change.
I thought I would post the answer here in case anyone else runs in to this problem. I've not found a 100% rock solid explanation, but we have managed to make it work and this has made me come up with a hypothesis as to the problem:
It appears that the compact framework seems to be taking the first Common Name (CN) off the "Subject Name Alternative" field of the SSL certificate and only evaluating the certificate against that whilst the full framework, IE and IE on the mobile device seemed to be using both. My reasoning for believing this is below:
The PDA application was accessing the url:
https://AMobileWebService.com/Webservice.asmx
Our old SSL certificate that worked had the following in the "Subject Alternative Name":
DNS Name=AMobileWebService.com
DNS Name=www.AMobileWebService.com
And the new certificate that did not work was contained the following in the same field:
DNS Name=www.AMobileWebService.com
DNS Name=AMobileWebService.com
When we changed the application to use https://www.AMobileSebService.com/Webservice.asmx, the old certificate (that was previously working) failed to establish a trusted relationship, and the new certificate worked (but previously did not).
As I mentioned earlier this leads me to believe that the .NET CF is only retrieving the first name in the SSL certificate and then evaluating the url host name against that, rather than doing it against both as in the full .NET Framework.
We came to this conclusion by implementing a "trust all certificates" work around that we found on stackoverflow:
https://stackoverflow.com/questions/6552598/system-net-webexception-thrown-when-consuming-a-web-service-over-https
The problem parameter on the workaround was returning the value -2146762481. Searching on hex representation of the value (0x800B010F) pointed me to the following information: https://blogs.technet.microsoft.com/rrasblog/2007/09/26/how-to-debug-sstp-specific-connection-failures/
The error turned out to be the constant : CERT_E_CN_NO_MATCH
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.
Today i received an email from apple telling they are changing something connected with push notifications, and wanted to ask what to do with the certificate they gave me link to... My server runs debian lenny, and im using php5 to send push notifications to apple apns. Do i have to just like... add it somewhere, or replace the 'old' one ?
Download the entrust_2048_ca.cer file, and install it on the servers that communicate with Apple's notification services. No need to do renew your actual push certificates, also you should not have to change anything in your code.
The important thing is that the servers that actually communicate with Apple's notification services have the certificate installed.
If you are lucky, your push server is already in contact with a Certificate Authority root, and this will solve the issue for you automagically. However, if you should lose that connection, your notifications will be out of order unless you have a "local" version of the certificate.
I am looking for the same solution, a quick hint from another forum says "simply download the .cer file and install it" http://www.iphonedevsdk.com/forum/iphone-sdk-development/66878-apns-question-email-apple.html.
We will try on our linux server and please see if this works for your situation.
I downloaded and copied the https://www.entrust.net/downloads/binary/entrust_2048_ca.cer file into /etc/ssl on my OpenBSD server. I haven't changed any of my server side code which is actually not using the entrust cert in any way. (I use the certs from Apple's provisioning site.)
On Dec 23rd, my notifications are sent and received with or without the entrust cert. I am confused about how exactly I am supposed to use the entrust cer file.
I think this sentence from the email from Apple tells me I am ok:
If you have been successfully
validating the certificate chain in
the APNs sandbox environment, you
already have the root certificate you
need. Simply install the same root
certificate on your production push
provider servers.
i.e.
Notifications were and are sent, hence my server already has what it needs.
UPDATE:
What I wrote above seems to be the case. If you use a fairly recent server you likely don't have to do anything at all. The sandbox environment has been using 2048 bits since March 2010. If it has been working, you are set. Full info here:
http://www.24100.net/2010/12/latest-apple-push-notification-certificate-changes-decrypted/
My PHP5 scripts that connect to the Apple Push Server are hosted on a Fedora system. For me, the migration was transparent. I had nothing to do despite I can't find the Entrust certificate somewhere on my system. Maybe is it available with the PHP5 SSL library.