Profile Manager Enrollment - iOS - Server Certificate Invalid

With regards to DNS, you're referring to a separate DNS server - not the Lion Server's DNS functions correct?

Yes, In our environment we use Windows AD to be the primary forward / reverse zones. If I do a nslookup for the shortname / FQDN for both forward / reverse on a End User machine, it should resolve the IP address of the OSX server in both directions.

Our lion server was setup to have a forward / reverse zone, and the server points to itself, but its not used for dns entries in our setup, the only entry is the server itself, and it has forwarders to forward everything to Microsoft DNS.

We're setup the same way here and we're good on the forward/reverse resolves.

Hmmm... "The server CERTIFICATE: "https://FQDN/devicemanagement/api/device/ota_service" is invalid..."

This guy had the same problem... I see where "bmike" enabled DNS on the server...

Our server was also named "hostname.local" initially (before my arrival here) and setup by someone else. Plus the server was upgraded. Throw that in with the forward/reverse DNS problem I discoverd, I can see how things are gummed up. Apple ran a EDC diagnostis session on the box and I'm waiting to hear back.

Also noticed: the keychain list in my AD network login profile is longer and contains more duplicates the what I'm seeing in the same place in a local admin profile... Strange...

Sorry for the late reply, i actually had to do some work :-)

Im guessing your certs are all screwed up, and thats why your having all these issues...

I took a screen shot of our certs so you can take a look. I blacked out a few things since I didn't want domain names to be visiable.

Something else I want you to try though as well, when you are enrolling in a device, are you using AD usersnames? Lets try using your local account on the server to see if that helps. It would be a good test to see if its a cert related issue or AD / OD

burton11234: no problem at all - you're doing me the favor so...

I tried the local login and got the same result unfortunately. Then I compared your certificate map to ours and saw several listed that looked like duplicates (they had the same names). Where we appear to differ:

- Your intermediate appears to list perhaps the local server name and FQDN (?)

mine only lists the FQDN

- You have 2 code signings: 1 listing the server name and the FQDN and one listing server name.local

I have one code signings which only lists the FQDN

- You have one (root ?) listing both the server name and the FQDN

I have 2 separate certs - 1 listing the server name - the other listing the FQDN

* Not sure which one is your OD certificate.

Either way, after deleting the three duplicate (older) certificates, I got the same problem.

So let's go back to basics. I think you're right - it's a certificate issue. Back to the error:

"The SERVER Certificate - blah blah blah DEVICEMANAGEMENT..." So if we go to the Profile Manager/Settings/Device Management (enabled and checked) - then click the EDIT button, the certificate that appears is my FQDN Code Signing certificate. What do you have showing there?

My guess is that it's NOT a code signing certificate... (?)

The only cert that I see is any different on your screen shot compared to mine, is the server.local code signing cert.

If I navigate to the profile manager settings under device management, it is enabled and checked. The cert im using is the FQDN.Intermediate-OD-CA Code Signing cert. Upon changing these certs, restart profile manager and web server.

Upon navigating to the page, make sure you go to FQDN/mydevices and download the trust cert prior to enrolling.

Once you have a public cert, you are no longer required to sign your configuration profiles.

Is that server currently using OD for any other services?

No OD isn't supporting any other services. What about Manage Devices, hardware network? One 3rd party guide says the Computer Name must be name.local for local network use and name.private "to ensure access to the server remotely". Mine is just set to computer name (no .local or .private). How about you?

that

Using the picture you are showing me, both the computer name and local hostname in that picture are both the short name of the server. "server"

The Hostname is the FQDN of the server.domain.com.

The UR: at the bottom under managed devices you blacked out would be http://server.domain.com/mydevices.

The reason why I asked you if you were using OD for any policies or users, was... I would remove OD, wipe profile manager with a script that restores it to defaults, and reconfigure everything again.

Its a fairly easy process, and if everythign is cleaned up, you shouldn't have any issues re-configuring things after. Sometimes if a hossed cert gets stuck somewhere it tends to screw things up!

I would be more then happy to give you the process if you want???

burton11234: I've already done the OD (and Profile Manager) tear down/rebuild at Apple's pre-EDC recommendation due to the earlier DNS issue but sure - go ahead and send the steps just in case I decide to try it again. I will be sure to post the fix here if that comes about. We're shopping for a Mac Mini with Lion Server installed now to stick out on the DMZ rather than this box anyway. The Mini will just be used for external ios management like your setup. Thanks.

You are downloading the trust profile before trying to enroll the device, right?

Yeah - it's on the device - verified and green. It contains two Certificates:

One is the OD certificate

The other is the FQDN certificate.

Other notes...

Here's a guy who rebooted to fix his problem...

Another interesting thread...

This thread suggests mailing a copy of the root certificate to the device first... More here about applying a "valid vs self-signed" ceritificate...

Note I also have "no services configured" in Profile Manager/Default Configuration Profile

These would be the steps I would take if I was going to rebuild everything.....

Verify OS is at 10.7.3 since there was major bug fixes done at each 10.7.x release....

These steps were done off the top of my head, so they should be fairly easy, although not exact step by step, i went through this process numerous times, and every time it was cert related.

The important thing here is that the FQDN Host Name matches the push certs and OD Intermediate certs.

Remove OD / Profile Manager

1) Stop all services

sudo serveradmin stop devicemgr

2) download Serveradmin tools http://support.apple.com/kb/HT5050

3) Launch Serveradmin and connect to your server.

- Go into Settings and change the server to a standalone server.

4) Kill profile manager.

sudo /usr/share/devicemgr/backend/wipeDB.sh

5) Launch Apple Push Cert Portal

- Server.app

- Hardware -> Select Server -> Settings -> Edit Enable apple push notifications -> Manage Certs

- Revoke All Certs

6) Adjust Hostnames...

- Server.app

- Hardware -> Select Hardware -> Network -> Edit Computer Name (Computer / Local should both be shortnames without .local)

- Hostname should corespond to the FQDN of your organization (ex. abc.company.com)

7) Open Keychain access and make sure the OD and code signing certs are removed, as well as any others, that involve the FQDN.

Reboot.

1) Open Server.app

2) Select Profile Manager -> Edit .... (you should be prompted to enter a diradmin password to create open directory)

This will also create your certs needed.

3) I would suggust removing kerberos, and binding it to the AD realm.

- verify AD is pulling usernames open terminal (id jsmith) or what ever username you want to use, you will see the AD groups be pulled.

- remove the OD realm (sudo sso_util remove -k -a diradmin -p "diradmin-password" -r "OD.FQDN.REALM"

(the realm needs to be exactly "CAPS" what it says if you open up serveradmin and go to open directory -> overview, and under kerberos realm)

- join to the AD realm (sudo dsconfigad -enablesso)

Now that OSX is in the AD realm we can move to the next step. You will see that kerberos is stoped in OD overview unlike before. This is recommended if your using the Magic Triangle.

4) Obtain the Push Certs

Launch Apple Push Cert Portal

- Server.app

- Hardware -> Select Server -> Settings -> Edit Enable apple push notifications -> Manage Certs

- Login, and acquire new certs, they should all match your FQDN when your in the web portion

5) Sign Config Profiles

- Open Server.app

- Edit Profile Manager

- Make sure "Sign Config Profiles" is checked and make sure your using your OD Intermediate Code Signing Cert.

6) Verify the Cert being used on the server is the correct cert. (***If you are using HTTPS***)

- Open Server.app

- Hardware (Select Server Name)

- Settings

- Edit SSL Cert

- Make sure Server.FQDN Intermediate CA is selected.

7) Restart Services if you change anything involving Certs.

Take a client, and download the trust cert first, and then enroll, it should work.

I will also be setting up the lab OSX server probably tomorrow, I can verify the steps for you as I am not reformating it, and it is a hossed box :-)

I will have the same setup as the production server not in the dmz, although in the lab. Ill let you know if anything else needs to be adjusted on configuration.

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.

burton1123: Was just also thinking - your well detailed rebuild recipe might save a LOT of people a LOT of grief for a LOT of different problems. It would be great if we could all team up to refine it (assumming the steps may not be step by step as you mentioned)... If I do execute it, I'll try to track anything I find...