There are are couple issues related to System Center Mobile Device Manager 2008 that I’ve addresses in a recent deployment I’ve been meaning to blog about, but was waiting on a couple responses back from Microsoft for confirmation. One is related to the externally-published Enrollment Server certificate and the other issue tackles the problem of using a Windows 2008 Certificate Authority.
Enrollment Server Certificate
The SCMDM deployment documentation states that all certificates should be deployed from the same certificate chain, meaning that all issuing servers chain up to the same root Certificate Authority.
This diagram from the Architecture documentation illustrates how the initial device enrollment process does not happen through an MDM Gateway server, but in fact an the Enrollment Server’s IIS website, which must be externally published to public hosts. this is typically performed through ISA Server, but any device or solution which supports configuration of a reverse HTTPS proxy can be used.
Upon first glance it may be assumed that a trusted third-party Certificate Authority will need to be used to issue an SSL certificate to that proxy (in this example an ISA Server 2006 Web Publishing Listener), as conventional wisdom leads us to believe that the site would need to be inherently-trusted by any connecting devices (by validating against any pre-installed trusted root certificates).
Well that assumption is incorrect in the case of SCMDM 2008. The typical deployment would leverage a Enterprise Windows Server 2003 internal Enterprise Certificate Authority to issue all certificates for SCMDM, including server, website, and device certificates. The requirement here, which I don’t find to be definitively clear in the documentation is that the certificate used on the externally published proxy for the Enrollment Server must also be issued by the same chain of authority as all the other certificates used in SCMDM. Meaning that a separate public certificate cannot be used on the external proxy or the device enrollment will fail, as it compares that certificate to the one that is issued to the device during the enrollment process. If the are not issued from the same root server (or issuing servers chaining up to the the same root CA) it will not complete.
By browsing to the site URL from a device (https://mobileenroll.contoso.com/enrollmentserver/service.asmx) will show the expected certificate trust security warning in the browser, but proceeding will still allow the page to be accessed:
The Windows Mobile 6.1 Domain Enroll function automatically suppresses any trust error as it expects to see an untrusted certificate, since the device has not yet been enrolled and added to the internal Active Directory. The process retroactively checks the certificate on the IIS site and compares it to the device certificate that is handed down to it by MDM and makes sure they are from the same authority.
Here is a recent discussion in the TechNet Forums with some more details and history on the topic:
http://social.technet.microsoft.com/Forums/en-US/SCMDM/thread/198a5667-570b-4bbb-8646-2f87d78fb1d0/
Windows 2008 Certificate Authority
The SCMDM deployment documentation specifically states that only Windows Server 2003 is supported for the enterprise certificate authority. The recently released Service Pack 1 adds support for Windows Server 2008 forest/domain configurations but still doesn’t list Server 2008 as a support CA.
Well after working with some members of the Premier Field Engineering Team they were able to test and validate a working scenario for environments with Server 2008 Enterprise CAs by deploying a 2003 Issuing subordinate CA to a 2008 root CA:
- Windows 2008 Enterprise Edition Root Certificate Authority
- Windows 2003 Enterprise Edition Issuing Certificate Authority
- Hotfix 951840 applied to the SCMDM Gateway Server
- The Windows Mobile 6.1 (Ipsecvpnpm.exe) hotfix is NOT required to be applied to the devices.
The 2003 server was used throughout the MDM deployment configuration to insure that all issued certificates for server components will match the device certificates.
