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?

Answered by Device Management Engineer in 781793022

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.

Accepted Answer

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.

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

WatchOS MDM Enrollment
 
 
Q