This question has to do with implementing a Windows Client Management enrollment server (ES). Per [MS-MDE] 3.5.4.1.1.1:
Because the enrollment client uses the existing certificate to perform client Transport Layer Security (TLS), the security token is not populated in the SOAP header. As a result, the ES is required to support client TLS.
However, this is impossible if the ES sits behind a SSL-terminating or SSL-bridging proxy. For MDM operations, an alternative is provided for this scenario using by including a signature for the SyncML request in the HTTP headers. Per [MS-MDM] 2.1:
When an MDM device establishes an SSL/TLS connection with the MDM server through SSL bridging–enabled proxies, the client device identity certificate obtained by the target MDM server from transport security will be the intermediate proxy server client authentication certificate instead of the actual device client identity certificate.<5> It is required that the MDM client and MDM server have a mechanism to send and verify device identity securely in this case. This is achieved by including a client certificate's related HTTP header in a DM package.
- Every SyncML message (section 2.2.2) that comes from the MDM client carries an additional HTTP header named MS-Signature and Authorization. This header contains a BASE64-encoded Cryptographic Message Syntax (CMS) Detached Signature of the complete SyncML message (SyncHdr, SyncBody) SHA-2 hash. Signing is performed using the private key of the device identity certificate.
However, the documentation does not describe how this may be included by the DM client for renewal requests sent to the enrollment server. Is this a supported use case, and is there a way to configure the DM client to authenticate renewal requests using headers?
