Profile Manager Enrollment - iOS - Server Certificate Invalid

burton11234: Many thanks for the last two posts. I may very well attempt the next to last.

An Apple recommended fix below (just received and didn't work for me but might help others) follows.

(BTW the Apple suggested steps below happen to contradict your next to last post - specifically the part about the cert FQDN Host Name matching the push certs and OD Intermediate certs requirement in Step 3 below: "leave everything at the default setting". When I create a new certificate ID, sequential numerals are appended to the end of the new cert name each time - thereby mismatching the existing push and intermediate cert names. *Others should note that for my server, these steps triggered a "EXC_CRASH (SIGABRT)" server application crash when choosing the "Always Allow" option in the "Server wants to export key FQDN from your keychain" dialog*).

1. Use Server.App to stop the web service and Profile Manager
2. In Server.App, click on your server's name under Hardware on the left, and then click on the Settings button on the right. Click Edit… button next to SSL Certificate. In the SSL Certificates drop-down, click on the gear button and choose Manage Certificates.
3. In the Manage Certificates drop-down click on the "+" sign and select Create a certificate identity. Leave everything at the default setting and click "Create"
4. Back in the SSL Certificates list change the Certificate menu to the new self-signed certificate you just created.
5. In a Terminal window run the following command: sudo serveradmin command web:command=restoreFactorySettings
6. Restart the server.
7. Go back into Server.App and start the web service (if it isn't running. Give it several minutes to start up)
8. Start Profile Manager service (if it isn't running).
9. Test.

I was having an issue with my ios device if I left out the end of FQDN. The Macs would enroll if I used https://server/mydevices but not the ipads. I have my search base populated from DHCP. They would get to the webpage fine. Download and install trust certificate. Click enroll would give me the ota cert not valid. I had to goto https://server.doman/mydevices. Then it would enroll.

I agree with you I do not have any issues with getting my OSX machine bound to the server, and to trust the profile and push down settings. Although I am not able to get the IOS device to do the same.

Upon the first time booting lion server up, i had got the ios device to enroll although there was many cert issues and the server just was to buggy, so i ended up reformating.

Profile manager crashed after enabling the wiki admin part and i had to run some commands to clean everything up. By then I was sick of playing games so i reformated. After that the push service worked and I had my certs straightened out. Although now Im not able to get any ios devices enrolled.

Any other idea's anyone?

I have even exported the certs, and trusted them, and emailed them to my device hoping this would help if the cert was already trusted, but nope....

the Problem is the cert, witch selected when activating devicemanagement, the used cert for singing profiles and registering by internet.

at my own it worked that way:

1 - setting up OD with registered FQDN Internet hostname (server.company.com)

2 - activating Devicemanagement before starting Profilemanager and selecting OD Intermediate cert

3 - setting up profilemanager and always using the OD Intermidiate cert, when cert was asked

4 - goto your internet router and define your server as DMZ target or deactivate your firewall

5 - calling https://server.company.com/mydevices and login with valid credencials

6 - got Profiles tab, click and install Trust Certificate. It must been showen as valid, after installing

7 - got to device tab back and click enroll. follow steps on screen. all should been done and ok

8 - refresh your profilemanager to see the device

9 - deactivate your Server vom DMZ an/or schwitch on the firewall

I have not find out wich ports on the firewall must be opend to do it without DMZ setting. I have to watch the fireall logs. I'm working on it.

hombre7777

@hombre7777

Thanks for the info. That makes sence what you are telling me. Their instuctions are kind of bland and dont make sence as much as they should.

The only thing that scares me on this one is now we need to put a device in the dmz....

So now upgrading our xserv to 10.7 when it becomes stable would now be using the magic triangle, and trying to only have 1 to manage osx machines / and now ios devices. Edit our wiki's thats already in place, and have important databases on filemaker is now going to reside in the dmz....

So someone wasn't thinking on this one!!! haha

It looks like we will have to seperate things now, so ios devices are managed on their own machine in the dmz with now a hole leaked in the firewall for AD to authenticate so we can pull users down to associate profiles with them.

Our osx machine will then contain a seperate spot to manage osx devices bound to user accounts, as well as manage filemaker and wiki's that are in use already.

It would be nice if they had figured out a way to do this a little different so we wern't opening holes in the firewall.

The funny thing is I was able to get the ipad to bind and enroll the very first time when i was on a vpn tunnel from my house trying things out.

So I know you can do it, without having to go public, although the push service wasn't working properly and I was not able to bind osx and enroll. So i stared over.

Ill play around to see what I can figure out later. Thanks for the help. If you find out the port numbers please let me know as well! Im not able to move the box to an outside firewall right now. I have to much to do. I can probably do that next week.

Hi. I have already got it.

Registering and enrollment all my devices works from inside LAN an from internet.

For sure its no option to place the server in the DMZ. It was only for testing and failure exploring.

Now I configured my enviroment as follow:

- adding a A record on internal DNS Server (server.company.com:my.local.ip.address), so the server will by routed inbound LAN direct and not by internet. outbound - Internet - it will be routed by FQDN to my Internet IP Address.

- activating port-forwarding on the router/firewall to my local server IP address

- Port TCP 443 -> my.local.ip.address

- Port TCP 1640 -> my.local.ip.address

- Port TCP 5223 -> my.local.ip.address

there was no more need to define access rules on dthe firewall for this ports.

After finishing this config it was possible to register all my devices, no care if in local network or thrue internet.

the only restriction is to install the true cert manually as I described in my last posting. Cause of self signed trust cert.

Hope this solution is helpfull for you.

hombre7777

Ill let you know how things turn out then.

Our DMZ is set up a little different then the normal. We still lock down all ports in the DMZ and then anyone in production can talk to DMZ but not the other way around.

This was done so incase something gets comprimised we will not be affecting our production network.

I will go through this first to see if we can get iOS devices enrolled just inside the network. Next week i'll have to re-ip and move to dmz so that way we can test out iOS devices on the outside then.

Thanks for the tip's they were much appreciated!

You need to enroll the device by its FQDN thats associated with the cert.

If you dont use the FQDN then you will will get a cert error when trying to enroll.

I would suggest trying to enroll with the device on the wifi before putting out in the wild just to rule out the firewall.

I have osx setup with the magic triangle and AD / OD is working and profile manager is working between iOS and MAC devices.

I will be getting another mac server to put in the dmz since virtualization is not supported with ESX 4.0 and we would have to upgrade our infrastructure to ESXi 5.0, and we are not doing that right now.

Once it is in I will update again and let anyone know if something doesn't work.

If you need any support just PM me if your allowed to do it through this forumn.

I've had this exact same problem, my Macs (iMac, MacBook) would enroll without a hitch, but any iOS device would give a certificate invalid message. Then, tonight, I finally figured it out: on all my OS X machines, I would connect to server.domain.lan/mydevices, which wouldn't resolve on my iPhone or iPad. I could reach the mydevices page but only through the direct IP address or the external domain name I have setup for the server - basically it's what burton11234 asserted: enrollment will only succeed if the domainname from where you're trying to enroll matches, exactly, the one on the certfifcate

What I had to do was edit the DNS list on my iOS devices, so that the server's IP address was first in line (on my iPhone, there were DNS servers, but not my Lion server; on my iPad the list was completely empty - just tap the DNS field under Settings - Network - Wi-Fi, then hit the little blue arrow next to the SSID). After that I switched to Safari, surfed to server.domain.lan/mydevices, and I could finish the enrollment.

I should perhaps mention that the trust certificate could be installed before changing the DNS settings, dunno why this is.

If the FQDN resolves by your default DNS server it will work, if the FQDN doesn't resolve by your defult DNS then you will have to point it to the OSX server which should be using a forwarder to the default DNS.

If its a public cert then the FQDN should be able to be resolved by any public dns server.

We use microsofts DNS servers, so there is a forward and reverse lookup in the DNS server to point to server.domain.com.

Your mac will most likly be able to enroll with just the short name if the cert is trust cert is trusted in keychain access, but iOS is very pickey and needs to be FQDN.

What type of devices are you trying to enroll?

Is your forward / reverse DNS working properly? (nslookup ip -> resolve dns name / nslookup dns name -> resolve IP)

Are you using AD / OD integration? (if yes did you stop kerberos and join it to the AD domain?)

burton11234: Thanks.

iPads

Forward/Reverse is working (now). This was an issue. Apple had me teard down OD and Profile Manager - then rebuild once corrected. So now:

$ hostname

(returns FQDN)

$ host (IP Address)

(Returns IP Address in-addr.arpa domain name pointer FQDN)

The server is bound to the AD and I can log in under those credentials. The server is an OD Master but we're not using OD to support account logons, just group creation/permissions for access to local shares. (hope that makes sense).

When you are registering iPad's are you using the FQDN or just the shortname, when enrolling the devices.

Ex.

https://mysever/mydevices

or

https://myserver.mydomain.com/mydevices

If you are using the shortname and not the FQDN when enrolling, it will create issues as well.

When i spent some time with apple on this one they wouldn't support me since I was using AD integration, although AD integration wasn't the issue at the time.

It doesn't matter if your testing internally, you still have to use the whole FQDN if you are enrolling an iOS device. I have been able to get away with just doing the short name with computers, since the domain search name is passed down by dhcp.

The open directory cert is created bassed on your FQDN of your open directory structure.

So if your OD certs are myserver.mydomain.com, you have to enroll the iOS device to https://myserver.mydomain.com/mydevices.

The cert doesn't know how to be pushed and accepted on the cell phone since if you go to "https//mysever/mydevices" its "not valid" because the cert was registered as mysever.mydomain.com and not myserver.

When I upgraded our XServ, we were using a hostname.localhost. This created issues after the upgrade to lion since our open directory cert was hostname.local. After riping out open directory, wiping profile manager, and changing the hostname, I was able to recreate open directory, and import all of my old data, and then setup profile manager.

It was a bit of work, for a mistake that happened almost 2 years ago from how the xserv was configured.

I hope some of this info helps....

OH and the reson why apple wouldn't support my senario when I was using AD / OD in the magic triangle..... They wanted a specific contract which was a waste of money to spend on a support contract, when I knew AD wasn't the issue in the end.

Thanks again. I have been using the whole FQDN syntax as I mentioned (

https://myserver.mydomain.com/mydevices) in case that might alter your next response. Wasn't even aware that you could use the short name version.