DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates

DirectAccess and Always On VPN with Trusted Platform Module (TPM) CertificatesTo 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.

  1. 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.
  2. 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.DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates
  3. Select the Cryptography tab.
  4. Choose Key Storage Provider from the Provider Category drop down list.
  5. Choose the option Requests must use one of the following providers and select Microsoft Platform Crypto Provider.DirectAccess and Always On VPN with Trusted Platform Module (TPM) Certificates

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

Trusted Platform Module (TPM) Fundamentals

DirectAccess and Always On VPN Certificate Auto Enrollment

Leave a comment

38 Comments

  1. Jamie Holmes

     /  March 12, 2018

    For 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!

    Reply
  2. Hello Richard

    does Always On VPn device tunnel work with TPM module for authenfication device?

    Reply
  3. Matt

     /  December 10, 2018

    Does anyone have Key Attestation working with AOVPN yet?

    Reply
  4. Volker

     /  August 29, 2019

    How can I enforce that only TPM certificates are accepted by the vpn Server?

    Reply
    • You 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.

      Reply
  5. Can this also be done with a Machine or computer certificate?

    Reply
  6. Hello 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

    Reply
    • 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.

      Reply
      • RE: 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

      • I 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, 2021

        Ok. I will give this a go, does it work for device tunnel as well?

      • Absolutely. 🙂

  7. Greg

     /  December 17, 2020

    Are there any requirements one the device ? EG TPM 2.0 or secure boot?

    Reply
  8. Harry John

     /  March 15, 2022

    We 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?

    Reply
    • You’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.

      Reply
      • Harry John

         /  March 17, 2022

        Hello 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

      • I’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, 2022

        Great – 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.

      • That 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, 2022

        Sure, 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?

      • Drop 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, 2022

        Hey 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!

      • Wow, that’s intriguing. That would seem to rule out a TPM-specific issue. :/

  9. Florian Obradovic

     /  July 29, 2022

    Key Attestation check works great. You can also create your own OIDs for EKU/Application Policies in the cert.template.

    In NPS console > Network Policy > Settings > Radius Attributes > Vendor Specific attribute: “Allowed-Certificate-OID” and enter the new OID of the Key Attestation you use:

    OID Key attestation type Description Assurance level
    1.3.6.1.4.1.311.21.30 EK “EK Verified”: For administrator-managed list of EK High
    1.3.6.1.4.1.311.21.31 Endorsement certificate “EK Certificate Verified”: When EK certificate chain is validated Medium
    1.3.6.1.4.1.311.21.32 User credentials “EK Trusted on Use”: For user-attested EK Low

    I tested it with 1.3.6.1.4.1.311.21.32 (User credentials “EK Trusted on Use”: For user-attested EK) and it works great.

    What doesn’t work unfortunately: adding multiple OIDs.
    Lets say you want to check for your custom OID (My-Company-VPN-User-Certs) to make sure only users with a specific, not only a valid cert. can connect + checking if the cert was issued using TPM Key Attestation.

    I don’t know if this a BUG, feature, Microsoft?

    If I add multiple OIDs to the “Allowed-Certificate-OID” in NPS, it seems that it always grants access, as long as one of the OIDs in the list matches.
    If others don’t match (by just changing just one digit for testing/validation purpose) it ignores it and still grants access. BUG, feature, Microsoft?

    In this case this is “secure enough” because:
    – the user anyway only gets the certificate with our custom OID, if TPM key attestation completes successfully
    – I can only check for my customAllowed-Certificate-OID

    Reply
    • That’s interesting, for sure. If you are on Twitter, pose the question to @crypt32 – Vadims will know the answer to that. Be sure to copy me on the thread!

      I agree, though, the need to match more than one OID might be a corner case. It’s not something I’ve ever run into myself. I typically issue certificates for single purposes, which would reduce or eliminate the need to check for more than one OID.

      Reply
  1. Always On VPN Certificate Requirements for IKEv2 | Richard M. Hicks Consulting, Inc.
  2. DirectAccess IPSec Server certificate expired and not auto renewed | Robin CM's IT Blog

Leave a Reply to VolkerCancel reply

Discover more from Richard M. Hicks Consulting, Inc.

Subscribe now to keep reading and get access to the full archive.

Continue reading