Profile Manager Enrollment - iOS - Server Certificate Invalid

Did you enroll for the push services on the server.app? This will push down 4 certs from apple to allow you to push to devices. I also had signed my profile, which required me to download the trust cert prior.

If you get a public cert you dont have to sign your profiles anymore. Although you do not need a public cert in order to do this.

I had it working over 3g devices with a self signed cert. Although our mobile server that handles iOS does not have AD integration on it. This type of practice goes against our security policys in the DMZ.

Our Xserv that is internal has no issues with AD / OD and profile manager though, but it is setup for push services and to sign the profile.

Yes - although I'm not seeing four APNS certs anywhere but that also may be because the machine isn't in the DMZ yet? Someone did speculate yesterday as to wether or not the APNS is needed for enrollment...

With regards to "you do not need a public cert in order to do this" I've seen at least two posts from people who seem to feel they solved a lot of issues with commercial certs... Then unless I'm misinterpreting, Apple even says; "The best resolution is to purchase and install a certificate on your server that has been signed by a well-recognized Certificate Authority (CA)." Not sure which way to turn here...

Your security policy towards an AD bound server in the DMZ makes absolute sense. I've already proposed a 2d server to mimic your Xserv role. Thanks for mentioning.

You have to generate the push certs from apple once you create OD. If you had previously created push certs, you will have to destory / update them in order to be on the same fqdn as your new OD master.

Open keychain access, go to System with the option highlighted for certs. You will see 4 certs if you have the push certs.

-APSP:xxxxx

-APSP:xxxxx

-APSP:xxxxx

-APSP:xxxxx

Your intermediateCA shoudl match with your AD FQDN dns entry, and you should see a code signing cert under your AD FQDN dns entry as well.

To generate the APSP certs from apple you need to go into server.app. Chose the server under hardware. highlight settings and edit the push notifications. You will have to use an apple ID in order to obtain these. After that you should make sure the SSL cert is chosen for the OD Intermediate CA cert from the local host.

Restart your services, and try again.

Let me know how it goes.

Even though people say to chose a real cert, you dont have to. I have had it working without one. Its personal preference. The only difference I found is with a valid cert, you dont need to download the trust cert before enrolling if you sign the profies under profile manager.

Okay:

I had all four of the APSP's but they wer UNTRUSTED. I trust all four now.

The IntermediateCA certificate name differs in that it's appended with a "_1" at the end. Marked "VALID"

Reads: "IntermediateCA_FQDN_1". Should it just be "IntermediateCA_FQDN"?

Footnotes:

1) There's also an untrusted root certificate called "computername.local" that matches the computer name of the server in Sharing: "computername".

2) In Sharing it says: "Computers on my local network can manage my computer using the address FQDN"

3) I have duplicate (2) "valid" FQDN certificates and duplicate (2) "signed by an unknown authority" Code Signing Certificates...

Thats fine tha tthe intermediateCA ends with a _1. Mine is the same.

-My APSP certs are listed as untrusted.

-IntermediateCA_FQDN_1 as trusted

-server.fqdn as trusted

- server.fqdn code signing as trusted

-server.local as untrusted (this is the only entry that should be server.local)

-Domain Cert from root CA is trusted

-software signing as trusted

Your duplicate certs, are they under system or login? (keychain access)

Does all of the FQDN's match from what your AD domain is, compared to the certs on OD, and the push certs as well.

How is your DNS set up on the server? My setup I have a static IP and the DNS server points to 127.0.0.1. I have the DNS server setup with a forward and reverse zone. The forward has the FQDN of the same dns entry that AD has.

Under settings on the DNS server, are you using recursive queries? I am using localnets and localhost (localnets is first)

Under the forwarder IP, I have our AD DNS servers listed there.

In ad there should be a forward and reverse entry for the FQDN as well.

"Your duplicate certs, are they under system or login? (keychain access)" All under system

Our server does have a static IP and it does have a 127.0.0.1 pointer.

Re: the DNS server, I'll have to run your points by one of the other Admins...

This will do it for me today - can't thank you enough. A very large state agency thanks you as well. Be back tomorrow...

Maybe we can just do a PM tomorrow or something like that, and I can send you some screen shots so we can see if we can clear things up. Some of the duplicate certs could be screwing things up as well.

Since profile manager is bassed off of certs entirly, its very finikey. It may almost be easier to distroy all certs, your OD master profile manager, and then run through the procedures again.

The only thing that seems to vary is that I killed the kerberos realm for OD, and joined it to the kerberos AD realm.

This could be affecting you...

Your not getting a permissions issue, so that means your AD users are able to have access to profile manager including the web part.

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...

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?

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.

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.

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...

When I ment your FQDN'S should match on your OD Intermediate as well as Push certs, they should both be in the format server.domain.com if there is any digits added to the certs, then obviously dont muck with that. That is system created.

Since everything is bassed on certs with profile manager, it is ncessary that the FQDN of the certs are all in the same format, so your puch certs should have the same fqdn if you log into the web session where you revoke the certs as your intermediate cert.

Like I said .... your settings are so mucked up, that the best thing to do is start over. There is no need to actually reformat... Just clean up all of your old settings, go remove some certs, and reboot.

I may have a small issue trying to test profile manager in the lab since the support for .local active directory domains was not introducted until 10.7.3, and the lab DNS zone was not working properly with our primary DNS zone in production.

Once again I got stuck working today and spent some time figuring out how to drop the wiki database so I could move the mini to the lab :-)

Gota love it when apple changes procedures every OS :-)