HTTPS with a device-held private key does not work on Windows or macOS

[marcschier]

Split out of #4192, which lets an application instance certificate keep its private key in a device (TPM, HSM, PKCS#11 token, KMS) so the key never enters process memory.

That works for UA-TCP on every platform. It does not work for HTTPS on Windows or macOS.

Why

The TLS layer there is the platform's, not .NET's: SChannel on Windows and the Security framework on macOS both require the key to be registered with a platform key storage provider. A key that lives behind a PKCS#11 module — or any other custom RSA/ECDsa implementation — is not, so the TLS handshake cannot use it.

On Linux it works, because the TLS layer dispatches through the managed key.

Scope

• UA-TCP is unaffected everywhere — this is HTTPS only.
• A deployment that needs both HTTPS and a device-held key on Windows today has to register the key with a platform KSP (CNG) instead of going through the provider model. The Windows CNG/TPM certificate factory added in Pluggable cryptography and hardware-held private keys (#4190) #4192 is the route for that, so the capability exists; it is the provider-model path that does not reach TLS.

Worth documenting explicitly in docs/CryptoProvider.md even if the platform limitation cannot be lifted, so the boundary is not discovered at deployment time.