memdocs
memdocs copied to clipboard
MicrosoftDocs
Fundamentally incompatible with the use of a device TPM and Key Attestation?
Can I sanity check that the way the Intune Certificate Connector's PKCS offering works, by generating the key on the server and not getting it from the client, is therefore fundamentally incompatible with wanting to use the device's TPM and Key Attestation?
If true, it might be worth amending the comment about where the private key is generated, to note that this also means that Key Attestation via TPM will not be possible.
Forcing us to use SCEP only, really devalues the Intune Certificate Connector for us. We're trying to stick to TPM-generated keys and heading towards enforcing Key Attestation as it gives us high assurance that a device certificate cannot be transferred to another device. There are other compromises such as having to let devices deal with the SCEP server directly. There must be a better way to do this.
Thanks.
Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
- ID: 41df2048-2b0e-4218-1fc4-d8a657f860cc
- Version Independent ID: e26c4390-87a3-7d5a-4e6f-529b4ccf8759
- Content: Use a PKCS certificate profile to provision devices with certificates in Microsoft Intune
- Content Source: memdocs/intune/protect/certificates-pfx-configure.md
- Service: microsoft-intune
- Sub-service: protect
- GitHub Login: @Brenduns
- Microsoft Alias: brenduns
For PKCS Import or PKCS the private key of the certificate is not generated on the device. For PKCS Import it is generated anywhere the IT admin does so. For PKCS it is generated on the server that is running the Intune certificate connector.
SCEP on the other hand generates the private key on the device that the certificate is delivered to. So to say that the Intune Connector only supports generating the private key on the server is not accurate. It supports both device generated keys and server generated keys.
Yes I have achieved Key Attestation with Intune using SCEP but this needs to be made clearer and that when you use SCEP you are limited to the template configured in the Registry. You'd literally need multiple NDES servers if you wanted to use multiple templates. It's not pretty and should be clearer.
I believe SCEP supports 3 templates but regardless you are essentially correct.
SCEP supports one template for signatures, one template for encryption and one template for "general purpose" (encryption and signatures). In the real world, we use certificates for signing and encryption in one, 99% of the time. Luckily for us, one template will do for now.
I've collected the details from the conversation and will review this at a future time for possible content changes - though the SCEP specific statements likely would be placed in the SCEP specific article.
It appears this issue might be resolved, so I will now close this thread. After closure, additional comments can continue to be added. To ensure they are seen, @ the individual you'd like to address the comment to.
