Profile Manager Enrollment - iOS - Server Certificate Invalid

I have been getting an error trying to enroll iOS devices into profile manager. My MacBook and iMac enroll just fine. However my iPhone and iPad do not.


When I enroll my MacBook Pro, I first log into https://(FQDN)/mydevices, select profiles, Install Trusted Profile. I then go back to devices, and click 'Enroll now'. When I check the Profiles section of System Preferences, I see that the 'Trusted Profile' has added two certificates refering to my server. I can only assume one matches the Self Signed I generated shortly after making my hostname public, and the other Apple Push generated for me.


However when I do this exact same process on my iPad/iPhone, when I attempt the 'Enroll Now' step, I get the error "The server certificate for "https://(FQDN)/devicesmanagement/api/device/ota_service" is invalid.


My searches for this issue have turned up issues close to this, but never exactly this, and the solutions don't seem to work for me. Here are some key points to note:


1. Tried demoting to standalone, re-promote to OD Master, then deleted all certificates, and regenerated all (including the Push cert from Apple)

2. Ran sudo changeip -checkhostname

3. DNS routes forward and reverse correctly in my local LAN

4. I had been getting "Remote Verification failed: (os/kern) failure" / "TEAVerifyCert() returned NULL" in my logs every 3 seconds until I did the steps listed in '1'


Looking forward to 10.7.1

Mac mini, Mac OS X (10.7), Server

Posted on Aug 10, 2011 12:38 PM

Reply
128 replies

Feb 20, 2012 12:47 PM in response to tmcmurtr

Well lets start by not assuming anything :-) That word seems to always get me when I assume something, without verifying.


Unless your core is a firewall, or your server subnet / user subnet are inbetween a firewall, then you shouldn't need any firewall rules.


If you have devices in the wild and use 3g. ex iOS devices then you would want to create a public DNS record and that record would have to match up with your FQDN's that you had an issues with earlier, and open a few ports up. Im guessing 2195 and 2196 would do the job. Although I would have to test that out in order to confirm. I cant remember why I had to open 5223, I think I was having issues with policys pushing for some reason, and thats why I opened that port up.


We have a device in the DMZ that only does iOS devices, and our production x-serv does laptops / desktops.

Feb 20, 2012 1:05 PM in response to tmcmurtr

That would make sence!


As to where the mini resides in the DMZ users can hit it from the public as well as the internal network. Although both sides are locked down by firewall rules. Our x-serv doesn't have any firewall rules, but then again its internal only.


My guess is 2195, 2196 and 5223 should be acceptable for pushing, although to enroll you will need 1640 and 443.

Feb 20, 2012 5:22 PM in response to burton11234

So what do I need to do to get this working? I've tried enabling root (logging in as root results in an security error on the enroll page).


changeip -checkhostname shows the same thing for both.


And yet I keep getting an error when enrolling Macs, iOS devices, and even the OS X Lion server itself. I get the same certficate error (with a '.bootstrap' added to the end of it).


Any ideas on what I could possibly do? I've been wrestling with this on and off for the last couple of months, and I'm really tired of it. This should not be this hard to get working.

Feb 21, 2012 5:37 AM in response to AbMagFab

@ AbMagFab


You dont need to enable root to get this to work, you should only use the root account if you must. When you run changeip -checkhostname that is being run on the host itself which may do a proper lookup, but are you using the dns server on OSX and pointing the host to itself? If so that type of lookup should always work.


You want to verify the FQDN of the host from a machine that is on the user subnet this can be done in windows or OSX by running "nslookup hostname.company.com" and "nslookup x.x.x.x" They should both resolve to the OSX server that has profile manager running on it.


That FQDN on the user subnet should then match up to the push certs you obtained from apple, as well as the OD certs that were generated upon configuration of open directory.


My best advice would be to revoke everything by running the script to clear device manager, blow away OD, by making your server a standalone member / server. Remove all certs that were valid, adjust DNS to work properly from the user subnet, and start over.


In other peoples cases, they have done the process correctly, although there may have been a stale cert that was left behind and was not revoked properly. There should be no need to reformat in any way if you remove everything properly. This process is not that time comsuming and is faster then to reformat / redownload form the internet.

Feb 29, 2012 11:06 AM in response to John B Portland

Hey guys!


I have a mac mini and having a tough time getting the profile manager setup the correct way. I think i need to start over and clean out what i have done so far. Whats the best way to do this? I have read thru the tread and and i have seen many different ways to do this. I just want to setup profile manager to help manage less than 60 iphones/ipads. So i would like to know whats the best way to clean up and start over?


Thanks for any information you can give me.


My setup is a Mac-mini lastest Lion server 10.7.3 (1.3.1)


Oh yeah i am new to the Mac world so a step by step would be great!

Feb 29, 2012 11:28 AM in response to TXED

Thanks for the quick responce DOLAdmin.


But look on Page 3 of the forum, and 5th post from the bottom of the page.


But there was also a few things that "DOLAdmin" found that were not exactly word by word from what I listed and he referenced those in another reply, they are on page 4 (4th post down from the top).


I would try going through these phases, since the exact process was listed already. I dont have any issues helping if needed, although most of the answers should already be in the thread :-)


If your looking on solutions on the Magic Triangle I have a sandbox PDF that may help with that one as well.

Mar 1, 2012 8:06 AM in response to TXED

Internet or Intranet?


The reason your iphone is coming up with that error is because of a FQDN issue with what the certs.


Can you do a forward / reverse lookup of the address on your local LAN? If so try to register with the FQDN on your ios device.


Did you setup apple push certs? If so, they need to be matched up for the FQDN and your forwrad / reverse lookup on your LAN, as well as the OD certs need to be in the same uniform.


If your server is called server.apps.net which it looks like thats what its called from your last post. You shoudl be able to do an nslookup server.apps.net on your LAN and resolve the IP, you should also be able to do a nslookup IP address, and it should resolve the hostname. If not please make sure that your forward / reverse lookup zones are correct.


After that is said and done, I would verify that the OD FQDN was created for server.apps.net and make sure your apple push certs say they were from server.apps.net.


Once everything alligns and you can reach the host server.apps.net from the public internet, you then should be able to enroll.


The reason why its failing is that an OSX system can use the shortname since they can trust the cert, although iOS devices need to be enrolled by the FQDN since there is no cert management done from the iOS device. If not everything matches, there is no enrolling....

Mar 5, 2012 6:57 AM in response to burton11234

Hi burton11234,


I've read everything in this thread and a bunch of other things on the web. At this point, profile manager it's an Intranet only install. It's a AD/OD Master install as well. Our intranet does not block ports and the mac server has the firewall off. When I reinstalled the OS from scratch during the "configure" stage it automatically creates the certs and I received an email.


As far as I can tell all certs are registered with the correct FQDN. I'm also using https://myserver.mydomain.com/mydevices to enroll these. But I still recieve the error "ota_service is invalid". I have the forward / reverse lookups working correctly. I'm connecting the ios device (ipad) to a wireless ap connected inside the intranet. I'm getting the correct dns servers on the ipad as well. A MBP is able to enroll just fine.


I can't seem to find the problem still. Any other ideas?


Also you said you have a PDF of a golden triangle. Can you post that somewhere I can download it?


Thanks for all the troubleshooting you've done this far for others.

Mar 5, 2012 7:47 AM in response to tdog0309

@tdog0309


From what you say, thats good you can enroll a MBP. Although the difference between an iOS device and OSX device is how they manage certs. iOS doesn't have a cert manager, and it handles certs differently.


If you are using a self signed cert on the server, you will need to donwload the trust profile on the iOS devices, after you install the trust profile you should be able to enroll. If your still having issues then there is some sort of mismatch on whats being used for the FQDN.


Just for clarification, when you signed up for the apple push certs, do they have the FQDN that coresponds to the same as when you do an "nslookup FQDN" on a client machine.


Here is a good artcile on the AD-OD configuration, it goes over basic authentication / configuraiton. Although your not using workgroup manager anymore since it moved to profile manager (aka devicemgr). Although the PDF doesn't specify the CLI commands to remove the kerberos realm of the OD master, and join the kerberos realm of AD. They do go over it in the GUI, but I never had good luck with the GUI. I did specify in my list of instructions about the "dsconfigad" command reguarding how to unbind the kerberos realm of OD and join the AD realm.


http://www.afp548.com/filemgmt_data/files/AD-OD%20Snow%20Leopard%20Sandbox.pdf

Mar 5, 2012 8:02 AM in response to burton11234

@burton1234


Yes the FQDN and the cert matched up correctly. I'm not sure what I did different but I tried downloading the trusted profile first and it worked as you said it would. This let me install the cert just fine after that.


I was trying this before and it wasn't working. I'm not exactly sure what caused the change but it probably was the cert. This thread was very helpful in setting this up correctly.


I'll take a look at the document and make sure I set that portion up correctly as well. Thank you for the link and your help.


One more question. When setup correctly are AD users suppose to be able to login to the enrollment area? Do i have to find each user in Profile Manager and check the box "Can Enable Remote Management"?

Mar 5, 2012 8:18 AM in response to tdog0309

Your welcome :-)


Glad you could get it up and running.


Requarding your question on AD.... If you have multiple domains in your forest please specify that your not going to use any domain in the forest to authenticate you. AD-OD gets ****** off when there is more then 1 domain in the forest. If you specify what domain your using it is a much happier environment and things work properly.


AD users can login to the enrollment area, you can adjust this by only allowing specific users if you want or groups. Normally this works by nesting an AD group inside an OD group and applying the security to the OD group on the mac environment. This way anyone that adds a user to an AD security group will have permissions to enroll if needed.


If you havn't download Server Admin Tools and connect to your OSX server via the "Server Admin.app". Once logged in Select the server and go to "Access" on the Group of Icons along the top of the application.


There will be spot for Services / Administrators. You can add groups in here to allow only specific users to login to specific services. AD users will be able to login these services once you have the proper AD/OD authentication configured.


The box "Can enable Remote Management" means the user was given access to administrate the server. Hope this info helps!

Mar 5, 2012 1:45 PM in response to burton11234

@burton11234


That was very helpful as well. Thank you. I think the last step is to get push notifications working. We don't block internal ports and the following ports going out from the server are open (80, 443, 1640, 2195, 2196, 5223) does any port incoming need to be open?


When I change the profile and it attempts to push the profile it just sits at sending and the device never gets it. I can confirm this in active tasks. Any thoughts here are welcome as well.

Mar 5, 2012 2:09 PM in response to tdog0309

Your more then welcome!


I would only use port 443 instead of 80 from the outside. (HTTPS is more secure then HTTP) The other ports that you listed were ports that need to be opened by either NAT (1 to 1) or port forwarding if your using Dynamic NAT (Router owns the public IP and you forward the ports to an internal IP)


These ports would need to be opened coming inbound. Our firewall rules from the DMZ to Untrust are (any any). So I dont have the proper outbound rules.


When you are talking about the profile is never pushed is this on IOS devices? If so it may be because the wrong firewall rules were created. I have also seen some odd things happen with my iphone 3g. We have Aruba Wireless controller with aruba ap-125's. They seem to be happy and push to most devices, although my iphone 3g sometimes has issues when the network is congested during the day.


You can also try pushing to the devices on 3g. With the ports opened for incoming that you listed do work over 3g access.


Does the server push to your macbookpro properly?


Another note is that I have seen some macbookpro's be picky, and they only push settings upon logging off / rebooting.

Mar 12, 2012 8:50 AM in response to TXED

OK i finally back to working on my mac mini push server! Had to stop for other projects. I am able to push the trust cert self signed (i am not using a purchased signed ssl cert) out to my iPhone 4 and i can i also push out a VPN profile setting as well. But i cannot enroll the iPhone 4 device with the profile manager. I get the following listed below when i try to click on enroll device from the iPhone 4 browser.


https://server.apps.net/devicemanagament/api/device/ota_service is invalid


Btw i am installing over the internet.


Thanks for any help.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Profile Manager Enrollment - iOS - Server Certificate Invalid

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.