WatchOS MDM Enrollment

We have a few development servers that implement MDM and I am trying to incorporate WatchOS Enrollment. I am having trouble connecting to our enrollment URL that is defined in the watch enrollment payload. The error I get indicates that the server certificate is invalid. I can see this error if I attempt to pair to an iPhone that has the WatchOS enrollment declaration on it and I also see if I send an iMessage with our server url and attempt to open the url using the messages app on the watch itself.

The certificate is valid, but the SAN does not define my particular domain but rather it uses a wildcard (i.e. DNS Name: *.domain.com and DNS name: domain.com).

The url opens fine on any other Apple device (iPhone, iPad, Mac, etc) as well as windows.

My question is, is there some problem with using an SSL server certificate that has a wildcard in place of a specific domain when attempting to connect using WatchOS?

Up vote post of rweiss Down vote post of rweiss
336 views
Posted by
rweiss
Reply
Add a Comment

Accepted Reply

watchOS trust evaluation does not behave differently on watchOS regarding the contents of the SAN. But there is one difference on watchOS which may be causing your problem: When the cert chain from leaf to root is incomplete, other Apple OSes attempt to download the missing intermediate certificates. watchOS does not do this. So make sure the server specified in the EnrollmentProfileURL provides a complete certificate chain, not just a leaf certificate.

Also, make sure that AnchorCertificateAssetReferences is correct. AnchorCertificateAssetReferences is a list of pinned certificates. If AnchorCertificateAssetReferences contains any entries, the server's certificate must chain up to one of those referenced certificates.

Posted by
Systems Engineer
Up vote reply of Systems Engineer Down vote reply of Systems Engineer
Post marked as solved

  • After reviewing, I believe the test program did not accurately reflect the cert chain. I used an openssl command to view the chain. I showed that the leaf was being returned twice, but no other certs were returned. I modified the load balancer certificate to return the entire chain. It appears to be working. Thank you for your help.

    —
    rweiss
Add a Comment

Replies

watchOS trust evaluation does not behave differently on watchOS regarding the contents of the SAN. But there is one difference on watchOS which may be causing your problem: When the cert chain from leaf to root is incomplete, other Apple OSes attempt to download the missing intermediate certificates. watchOS does not do this. So make sure the server specified in the EnrollmentProfileURL provides a complete certificate chain, not just a leaf certificate.

Also, make sure that AnchorCertificateAssetReferences is correct. AnchorCertificateAssetReferences is a list of pinned certificates. If AnchorCertificateAssetReferences contains any entries, the server's certificate must chain up to one of those referenced certificates.

Posted by
Systems Engineer
Up vote reply of Systems Engineer Down vote reply of Systems Engineer
Post marked as solved

  • After reviewing, I believe the test program did not accurately reflect the cert chain. I used an openssl command to view the chain. I showed that the leaf was being returned twice, but no other certs were returned. I modified the load balancer certificate to return the entire chain. It appears to be working. Thank you for your help.

    —
    rweiss
Add a Comment

"make sure the server specified in the EnrollmentProfileURL provides a complete certificate chain, not just a leaf certificate"

it does

"Also, make sure that AnchorCertificateAssetReferences is correct. AnchorCertificateAssetReferences is a list of pinned certificates. If AnchorCertificateAssetReferences contains any entries, the server's certificate must chain up to one of those referenced certificates."

I have tested this by including the leaf, intermediate, and root certficates individually and together (3 different assets included in the anchor cert list). It still is not working. BTW, the server cert is chained to a trusted CA (as far as I know).

leaf is signed by the following intermediate:

CN = Thawte TLS RSA CA G1 OU = www.digicert.com O = DigiCert Inc C = US

and the intermediate is signed by the following root CA which is self signed root and should be trusted (unless there is something I don't know):

CN = DigiCert Global Root G2 OU = www.digicert.com O = DigiCert Inc C = US

In any event, even if any of the certs are not trusted, including them in the anchor cert list should implicitly trust them. I've been able to enroll on my local Windows IIS deployment with a self signed root/intermediate/leaf with no problem by including them in the anchor list.

Posted by
rweiss
Up vote reply of rweiss Down vote reply of rweiss

  • You can check this page for the list of trusted root certificates in Apple operating systems. If your server cert's final CA is in that list, you don't need to specify AnchorCertificateAssetReferences at all.

    It's still possible that the watch is not able to construct the complete certificate chain. Is your server only providing its leaf cert (and therefore relying on clients to download one or more intermediates)?

    —
    Systems Engineer

  • If the server is providing the full certificate chain and you've ruled out the cert trust issues discussed above, it will likely help to examine the log events from the device. See these instructions for capturing a sysdiagnose from an Apple Watch. You can examine the contents of the sysdiagnose using the log command on a Mac. You can also submit it to Apple, attached to a developer feedback.

    —
    Systems Engineer

  • I have found the root cert in the link you provided, so according to your comment, I should not have to specify any AnchorCertificateAssetReferences. I wrote a test program to see what certificates are returned (a simple get to my dev server). The X509Chain includes all 3 certs. Leaf, intermediate, root.

    I will attempt to get the sysdiagnose logs and examine them. If I can get them, I'll submit them as well.

    —
    rweiss
Add a Comment