Profile Manager Enrollment - iOS - Server Certificate Invalid

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.

For anyone willing/able to assist here: I'm in Certificate failure/troubleshooting phase now with the same error:

"The server certificate for "https://(FQDN)/devicesmanagement/api/device/ota_service" is invalid." when I try to enroll my iPad.

Apple had me run an EDS diagnostic to send to them (still waiting for results) but it sounds like a couple of you have solved this issue by (correcting me if I'm wrong) replacing your self-signed certificates with commercial ones?

Right now I have a "Verified" Trust profile installed consisting of the signing certificate and two other certificates - one matching the FQDN.

Any help appreciated - thanks.

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.

Burton11234: https://myserver.mydomain.com/mydevices. Should have mentioned I'm doing internal testing before facing it towards the public and using a self-signed certificate.

Not sure of any relation but I'm also becomming aware of people reporting (and here) sucess at solving problems with certs issued by commercially trusted vendors as opposed to self signed - even for testing - and (I'm assumming) - even though a trust profile certificate is installed and verified. Sound similar to the problems you were having?

Not sure I understand why there might be a support issue because a machine happens to be AD integrated - a feature they've been laboring on perfecting/improving for quite some time now.

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.

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.