Error sending device policy update request

[Migration User]

Hi guys.

 

I have configured a Symantec MDM POC and have had a device sucessfully enroll, hoever I get an error when attempting to send a policy update:

Exception Details: System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

 

I would have thought that it would refuse to enroll if there were any issues with certificates, but that is what the error message is eluding to.

 

Any help would be appreciated.

 

Cheers.

[Migration User]

Where do you see this error displayed?

What OS is the device?  How is it connected?

Did you specify an override URL to provide to clients, and if so, what is it?  Are they connecting over HTTPS?  Is the HTTPS cert externally-signed?  Does the override URL match the SSL certificate?

[Migration User]

Error is displayed in the Altiris Log app.

iOS 5 and I am running SMM 7.1 MR1

I did specify an override URL for the test domain I have setup. It has an SSL cert signed by a trusted authority and it is set to the HTTPS binding in IIS. The override URL does match the one issued to the SSL cert.

Cheers

[Migration User]

Is your Mobile Management server on the same box as the SMP or a different server?

[Migration User]

Same server

[Migration User]

Is 'Require HTTPS' checked in IIS for the Default Site?  It appears you're requiring SSL somewhere when it was not expecting SSL to be required.  This is logged on the NS at the moment when you assign the task?

Does a simpler command such as 'Lock Device' work, or do all right-click actions fail?  I am suspecting that the NS is accessing a local name over HTTPS and it's not resolving properly.  Are all of these systems on the same domain?

Did you install .NET on the MMS SS?  If you access https://mms.companyname.com, you should get an IIS7 image, where mms.companyname.com is the FQDN of your MMS SS.  If you access https://mms.companyname.com/MobileEnrollment/Symc-iOSEnroll.aspx, you should see the word 'success' on the page.  Finally, if you visit https://mms.companyname.com/MobileEnrollment/MobileConfig.aspx, you should be prompted to download a file.  If you get gobbledegook, you are missing .NET on your MMS SS.  If that happens, uninstall the SS components using the uninstall policy, install .NET, and reinstall the SS (manual execution of Mobile Service.msi would be the easiest way to do this).

[Migration User]

I can browse those pages and get the results you describe.

 

I didn't have 'Require SSL' checked under 'SSL Settings' for the Default Web Site in IIS Manager.

I do have 'Use https' checked under the override settings, as it appears iOS 5 devices reject the profile unless it is delivered over HTTPS.

 

'Client certificates' in IIS for Default Web Site was set to ignore however so I'll set that to accept and try and re-enroll and post the results.

Cheers

[Migration User]

Ok, setting client certificates under SSL setting to accept rather than ignore causes the enrollment process to time out. Setting it back to ignore allows it to enroll - strange.

 

Also it seems it takes a long time for my posts to appear in this site - they must be getting QA'd before they are published?

[Migration User]

Also, looks like all right click - iOS actions result in either a similar error or the same.

[Migration User]

Perhaps Mollom, the spam filter, is catching them, and then they require approval?  I know I haven't been getting notifications on some threads, so I'll pass this on as well

iOS devices will indeed require iOS 5.

On your MMS SS, you will have a folder like C:\Program Files\Symantec\Mobile Management\Data\nlog (or similar -- not at a box at the moment).  What are the relevant errors from the logs for the most recent day?  You may want to send a right-click > Update Policies 2-3 times in a row prior to checking the logs so you can see the errors for the date/time when you tried a right-click action, just to be sure.

[Migration User]

The entry that looked like it may be related was in the NT_APNS_PUSH log:

2011-11-24 14:34:01.9095 INFO  Creating new connection to APNS
2011-11-24 14:34:05.6900 ERROR Error in ReceiveCompleted inner catch
2011-11-24 14:34:05.6900 INFO  A call to SSPI failed, see inner exception.
2011-11-24 14:34:05.6900 INFO  InnerException: The certificate chain was issued by an authority that is not trusted
2011-11-24 14:34:05.6900 WARN  requeuing push message - see previous errors
2011-11-24 14:34:05.6900 INFO  Pausing processing for 900000 due to error sending

Is this refering to my APNS cert or the SSL cert for my domain do you think?

Appreciate the assistance.

[gewu]

Guys,

is there any progress on this matter ?

thx in advance

[Migration User]

I'm going to engage some help from Symantec. Once I know why this error is occuring I'll post it up.

[Migration User]

I'm going to go with SSL.  Your APNS cert just needs to be installed on the MMS SS, with Read rights given to Network Service.  I assume your APNS cert has a bundle identifier that's com.apple.mgmt.* where * is whatever you want.

But I still say it seems like SSL.  Is your NS accessing the MMS SS by its FQDN?  If it's accessing a local name rather than FQDN, that could be the error mentioned in the log.  But you're seeing that in the log on the MMS SS, not the NS, so perhaps that's not the case.

Have you looked at the certificate chain error?  For example, the certificate chain is mentioned on this page and offers useful troubleshooting tips on what to check in the Certificates snap-in:
http://technet.microsoft.com/en-us/library/bb794843.aspx

[Migration User]

Yes, double checked the subject/identifier is correct and the Network Service has read rights under Manage Private Keys. I'll re-do that process just in case.

I'll have a look through that article and see ifthere is anything that correlates with what I'm experiencing and if there are any issues with the chain in regards to CA's etc.

 

Cheers

[Migration User]

Ok, I re-keyed my SSL certificate, ensured that the Intermediate certificate was installed prior to completing the signing request and checked the cert chain after completing it. Re-imported the push cert, double checked thumprint was correct, reapplied the Network Service with read permissions under security for the private key. Same issue.

Hopefully the person from Symantec I'll be chatting to soon will be able to shed some light on what I may have done wrong.

[Migration User]

What is your https binding certificate in IIS set to? Is this the same or different to the signed certificate you got for communication to iOS 5 devices.

From what I can tell, the server is communicating to the APNS through https as a name (FQDN, CNAME, IP Address) that is a different name from your signed certificate.

[Migration User]

The certificate that is binded is the SSL cert I have signed by the public CA - same common name/domain name that is used to for comms to the iOS 5 device.

[Migration User]

Our IT Sec department poured cold water on being able to enroll from outside from the Internet (they'll enroll via internal WiFi), so that made my job a little easier. So I ended up signing the SSL certificate for IIS with my internal CA, binded that to the site. I added the root CA certificate into a 'Credential' payload' and added that to the iOS MDM Enrollment Configuration as an additional configuration profile to include.

When enrolling you still initially get the message that the certificate is untrusted when choosing to enroll through the agent and when it switches to Safari to initially push the profile to the device - however the profile application process seems to deliver the 'Credential' payload first, allowing the trust to be there before the profile is fully applied, allowing it to enroll successfully and SCEP cert to be issued on my iOS 5 device.

I've got issues with APNS traffic getting out on ports 2195/2196 in my test environment, but I'm confident that I can get past that.

Thanks for everyones input.

[Migration User]

Glad to hear you got yours resolved ExecD.

I tried to mirror your approach but even with pushing the certificates as initial payloads it didn't work for me.  Most of my issues stem from our domain name being different to our public facing domain.

There is an excellent article with a workaround relating to the https bindings, etc here, however due to us being unable to get a signed cert for our FQDN, not workable.

My solution is hacky but it works a treat. I moved all the enrollment and SCEP urls to https port 444 and bound that to my public domain trusted cert. Then communication from the server to APNS can use https 443 using the self-signed FQDN cert.

The device enrolls without drama and there's communication from the mdm server to APNS and down to the device now.

I've updated our Symantec case with the above info to run it past them. I'm not happy with this setup but it's what we need to move forward.