To enhance security when provisioning certificates for DirectAccess (computer) or Windows 10 Always On VPN (user) it is recommended that private keys be stored on a Trusted Platform Module (TPM) on the client device. A TPM is a dedicated security processor included in nearly all modern computers. It provides essential hardware protection to ensure the highest levels of integrity for digital certificates and is used to generate, store, and restrict the use of cryptographic keys. It also includes advanced security and protection features such as key isolation, non-exportability, and anti-hammering to prevent brute-force attacks.
To ensure that private keys are created and stored on a TPM, the certificate template must be configured to use the Microsoft Platform Crypto Provider. Follow the steps below to configure a certificate template required to use a TPM.
- Open the Certificate Templates management console (certtmpl.msc) and duplicate an existing certificate template. For example, if creating a certificate for DirectAccess, duplicate the Workstation Authentication certificate template. For Always On VPN, duplicate the User certificate template.
- On the Compatibility tab, ensure the Certification Authority and Certificate recipient compatibility settings are set to a minimum of Windows Server 2008 and Windows Vista/Server 2008, respectively.
- Select the Cryptography tab.
- Choose Key Storage Provider from the Provider Category drop down list.
- Choose the option Requests must use one of the following providers and select Microsoft Platform Crypto Provider.
Note: If Microsoft Platform Crypto Provider does not appear in the list above, got to the Request Handling tab and uncheck the option Allow private key to be exported.
Complete the remaining certificate configuration tasks (template display name, subject name, security settings, etc.) and publish the certificate template. Client machines configured to use this template will now have a certificate with private key fully protected by the TPM.
Additional Resources
Jamie Holmes
/ March 12, 2018For extra assurance, you can also enable Key Attestation using either Endorsement Certificate or Endorsement Key mode.
This is to verify that the certificate is definitely being issued to a TPM, and not a crypto provider that’s simply been renamed!
Richard M. Hicks
/ March 12, 2018Thanks for the tip, Jamie! I’ll be authoring a post on that topic hopefully soon. 🙂
Eric Yew
/ June 13, 2018Any update on when this post will be available? Thanks!
Richard M. Hicks
/ June 15, 2018It’s still on my list, just haven’t gotten to it yet. Here are some details from Microsoft – https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation.
Enjoy!
Eric Yew
/ June 17, 2018Yes, have tried it but unfortunately it’s not as easy as the document states. I configured as per documentation utilising “Trust based on user credential” and the VPN will never connect. The moment I disable TPM attestation and reissue the cert, it works. Any help or directions would be greatly appreciated. Thanks.
Richard M. Hicks
/ June 18, 2018Sorry to hear that. This is not a common requirement in my experience, so it’s not a high priority at the moment. However, I’ll try do some validation testing when time permits and let you know what I find.
Patrick
/ June 11, 2018Hello Richard
does Always On VPn device tunnel work with TPM module for authenfication device?
Richard M. Hicks
/ June 11, 2018It certainly can. 🙂
Matt
/ December 10, 2018Does anyone have Key Attestation working with AOVPN yet?
Richard M. Hicks
/ December 10, 2018I’ve done some testing in the pass and didn’t have any issues. Which trust model are you using?
Matt
/ December 10, 2018I haven’t tried it, but I have only seen failures posted with no solutions. So, I didn’t want to attempt it if it isn’t known to work.
Richard M. Hicks
/ December 10, 2018It’s not trivial to get working correctly, but it is possible. Best documentation and guidance for enabling/configuring key attestation can be found here: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation.
Volker
/ August 29, 2019How can I enforce that only TPM certificates are accepted by the vpn Server?
Richard M. Hicks
/ August 29, 2019You can really configure the VPN server to only accept certificates with private keys store on a TPM. What you can do is ensure that clients can only use a TPM with this certificate template (as outlined in this post). You can take additional steps to increase assurance that key material is generated and store on a TPM by using key attestation as well.
korman
/ July 9, 2020Can this also be done with a Machine or computer certificate?
Richard M. Hicks
/ July 10, 2020Absolutely, and recommended.
ced666
/ November 15, 2020Hello Richard
Is Microsoft Platform Crypto Provider. supports ECDSA type algorithms? because I don’t see the Microsoft Platform Crypto Provider when I select ECDSA.
Does this mean that the ECDA private key cannot be protected via the TPM chip?
Thank you
Patrick
Richard M. Hicks
/ November 17, 2020It does not. If you want to use TPM (recommended) then you must use RSA client authentication certificates. You can still use ECDSA for IPsec though.
Martin
/ July 30, 2021RE: It does not. If you want to use TPM (recommended) then you must use RSA client authentication certificates. You can still use ECDSA for IPsec though.
I have tried and tried to get this working – can you point me in the right direction for this. I have put an ECC cert on the RRAS server and an RSA cert on the NPS server, or just an RSA Cert on the client or both RSA and ECC on the client. or almost every combo of the above. I cant see a away to have ECC cert for encryption and RSA for authentication. Any help what so ever would be fantastic. Martin
Richard M. Hicks
/ July 30, 2021I do this all the time and it works perfectly. 🙂 The only EC certificate that’s required is the certificate on the VPN server. You’ll use RSA certificates on the NPS server and for client authentication (user certificate). If you can’t get it working, reach out to me directly and I’ll provide you with more information.
Martin
/ July 31, 2021Ok. I will give this a go, does it work for device tunnel as well?
Richard M. Hicks
/ July 31, 2021Absolutely. 🙂
Greg
/ December 17, 2020Are there any requirements one the device ? EG TPM 2.0 or secure boot?
Richard M. Hicks
/ December 22, 2020Just TPM 1.2 or later. No need for secure boot.
Harry John
/ March 15, 2022We have a problem with this provider:
After some time off the corporate network, our clients get the VPN error “A certificate could not be found that can be used with this Extensible Authentication Protocol”
In the CAPI2 logs we see “Keyset not found”.
After some time on the corporate network, this issue goes away.
If we force a connection to the always on VPN whilst actually connected to the corporate network, it always immediately solves the issue.
A Wireshark capture shows that the client is doing an MS-BKRP request to the domain controller – if it cannot contact the DC (i.e. when not on the network), the private key of the user certificate cannot be read.
We have the following errors in DPAPI logs:
“Master Key decryption failed because the encryption cred mismatches the decryption cred.”
We’re using Dell computers less than 3 years old, on Windows 11, so TPM 2.0 is available.
We are considering switching to Microsoft Software Key Storage Provider – currently Microsoft Platform Crypto Provider is the only provider selected.
This is a new AlwaysOn VPN deployment, and we followed the MS deployment guides exactly.
Any ideas?
Richard M. Hicks
/ March 15, 2022You’re not alone here, unfortunately. This is a common issue, in fact. I’m not sure if it is a bug or not, but it sure sounds like one. Moving to software KSP will fix the problem, but then introduce the risk that certificates can be more easily compromised. Not exactly cool for a remote access solution. You’ll have to decide what your assurance requirements and risk appetite are and make the decision. Can’t blame you for going software KSP though just to ensure reliability.
Harry John
/ March 17, 2022Hello Richard,
Thanks a lot for the reply. Are you aware of any other online reports of this or is it first hand experience? I’ve been searching and searching to the point where I question my Google skills!!
That’s great to know that I’m not alone here… hopefully TPM/MPCP will mature in time and we can switch back in the future.
All the best and thanks again
Richard M. Hicks
/ March 17, 2022I’m not aware of anything published at this point. I have at least 7-8 customers over the last year reporting the same exact issue, however. It can be unique. I might do a write-up on this and ask for comments. It would be interesting to see how many people respond. 🙂
Harry John
/ March 17, 2022Great – I’m not going mad! That also rules out Windows 11 specifically if you’ve had plenty of reports over a year. I suspect the uniqueness is hardware dependent on the TPM. I have quite a bit of content I’d be happy to share, including Wireshark captures and error logs – if that’s helpful for any future write-ups just let me know and I’ll send it over. Thanks Richard, love your website.
Richard M. Hicks
/ March 17, 2022That would be great. It is difficult for me to document because I’m unable to reproduce this issue myself. Having some reference information would be beneficial. I’m happy to look at whatever content you’d like to share!
Harry John
/ March 17, 2022Sure, I’d be happy to! How would you like me to send you screenshots and details, do you have an email address you can share?
Richard M. Hicks
/ March 18, 2022Drop me a note here: https://directaccess.richardhicks.com/contact/. I’ll respond and you can send me those assets then.
Thanks!
Harry John
/ May 26, 2022Hey Richard, FYI I sent you a message there but not sure I got a reply.
On another note – I’ve started getting the exact same DPAPI errors despite switching to Microsoft Software Key Storage Provider and now I’m at a complete loss. Strange, because switching to this has solved the issue for everyone else at my place at work – and me too for a few months!
Richard M. Hicks
/ May 26, 2022Wow, that’s intriguing. That would seem to rule out a TPM-specific issue. :/