Always On VPN Device Tunnel and Certificate Revocation

Always On VPN Device Tunnel and Certificate RevocationRecently I wrote about denying access to Windows 10 Always On VPN users or computers. In that post I provided specific guidance for denying access to computers configured with the device tunnel. To summarize, the process involved exporting the device certificate from the issuing Certification Authority (CA) server and placing it in the Untrusted Certificates certificate store on each VPN server. In theory, simply revoking the device certificate should be all thatโ€™s required to prevent device tunnel connections.

Revocation Check Failure

As it turns out, a bug in Windows Server Routing and Remote Access prevents this from working as expected. Windows Server 2012 R2, 2016, and 2019 all fail to check the Certificate Revocation List (CRL) for IKEv2 VPN connections using machine certificate authentication (for example an Always On VPN device tunnel).

Updates for Windows Server

Microsoft has released fixes to support device tunnel certificate revocation for the following operating systems.

Windows Server 2019 – KB4505658 (build 17763.652)

Windows Server 2016 – KB4503294 (build 14393.3053)

Windows Server 2012/R2 – Will not be updated.

Enable Revocation Check

Additional configuration is required to enable support for CRL checking. Microsoft published guidance for configuring CRL revocation checks for IKEv2 VPN connections using machine certificate authentication here. Specifically, administrators must enable the RootCertificateNameToAccept parameter and set a registry key to enable this functionality.

Open an elevated PowerShell window and run the following commands to enable CRL checking for IKEv2 VPN connections using machine certificate authentication.

$Thumbprint = ‘Root CA Certificate Thumbprint’
$RootCACert = (Get-ChildItem -Path cert:\LocalMachine\root | Where-Object {$_.Thumbprint -eq $Thumbprint})
Set-VpnAuthProtocol -RootCertificateNameToAccept $RootCACert -PassThru

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\’ -Name CertAuthFlags -PropertyTYpe DWORD -Value ‘4’ -Force

Restart-Service RemoteAccess -PassThru

Always On VPN Device Tunnel and Certificate Revocation

A PowerShell script to update the RootCertificateNameToAccept parameter on multiple VPN servers can be found here.

Revoking Certificates

To prevent a Windows 10 Always On VPN device tunnel connection, the administrator must first revoke the certificate on the issuing CA. Next, open an elevated command window an enter the following commands. Repeat these steps on each VPN server in the enterprise.

certutil -urlcache * delete
certutil -setreg chain\ChainCacheResyncFiletime @now

Additional Information

Denying Access to Windows 10 Always On VPN Users or Computers

Blocking VPN Clients that use Revoked Certificates

PowerShell Script to Configure RootCertificateNameToAccept on GitHub



Leave a comment


  1. Simon

     /  June 24, 2019

    This sort of bug is unforgivable… not bothering to check if a certificate is revoked? RRAS has absolutely no place in a modern IT infrastructure, it’s absolutely shocking.

    • It is surprising to learn this bug has apparently been around and unfixed for so long. It’s important to note also that Windows Server 2012 R2 is affected, but Microsoft won’t be releasing a fix for that version. You’ll have to upgrade or replace it with a proper security appliance, which I suspect would be your choice. ๐Ÿ˜‰

  2. John

     /  July 16, 2019

    Hi Richard
    I have a Server 2016 Device Channel VPN configured in a DMZ and working fine. Clients connect on a daily basis. I followed the steps above and set the CertAuthFlags registry flag to “4”. Afterwards, clients can connect but none of the routes are working in that client session.
    Reversing this and setting the CertAuthFlags back to “2” disable the function, fixes the routes again. Any idea what could be causing this?
    Regards John

    • That’s quite unusual. Certainly not something I’ve seen in my testing. Also, I can’t imagine how changing CRL checking would impact routing? Odd. Are you able to reproduce this reliably? I ask because there is a known issue with RRAS that sounds similar. There’s currently a bug that will result in VPN connections being established but routing fails. The only workaround is to restart the server (restarting the service isn’t enough). I’m curious to know if perhaps these two issues aren’t being conflated here somehow.

      • Fredrik

         /  November 11, 2019

        Hi Richard
        Do you have more information about this bug? I am currently experience the same problem. Routing fails and i have to restart server to get it working.

      • I don’t have any more information other than Microsoft is aware of the issue. No idea if they are working on a fix or not. :/

  3. Dirk Rober

     /  January 2, 2020

    The link for “PowerShell Script to Configure RootCertificateNameToAccept on GitHub” does not seem to work anymore. Can you point me to a working location?

  4. Is it possible to trust multiple root CA’s? I’m digging around but just in case you’ve come across this thought I’d post to help any others as well.

    • No. If you need to support Always On VPN device tunnel with certificates issued by different PKIs, you’ll have to implement separate VPN servers for them. :/

      • Ok, just to be 100% clear. The VPN is supporting:
        – IKEv2 device tunnel, with an internally-issued cert with the fully-qualified service name as the subject name.
        – SSTP user tunnel, with a publicly issued wildcard cert

        What we’re seeing in in the client CAPI log is the VPN server seems to be presenting the wildcard cert when the device is getting set up.

        Also, thanks for clarifying the issue around trusting multiple CA’s for IKE connections as that is also a requirement!

      • Thanks Gavin. Does the certificate issued to the VPN server for the IKEv2 device tunnel connection by your internal CA include both the Server Authentication and IP security IKE Intermediate EKUs? It must include both.

  5. Stefan Hattrell

     /  April 6, 2020

    Hey Richard! Love your work. I’ve pretty much used your blogs to stand up our Always-On VPN.

    I’m now setting up a second server for failover and have gotten to this point but I’m getting the following error: “Set-VpnAuthProtocol : The parameter is incorrect. invalidArgument: (PS_VpnAuthProtocol:root/Microsoft/…VpnAuthProtocol) [Set-VpnAuthProtocol], CimException”

    This worked beautifully on the first server and I’m scratching my head to understand how it’s any different!

    • Has RRAS been installed? If so, has VPN been configured?

      • Stefan Hattrell

         /  April 6, 2020

        Ah! Figured it out. I hadn’t actually enabled machine certificate authentication as a method…

  6. BWorrall

     /  May 24, 2020

    Hey Richard, long time fan while doing our AOVPN deployment ๐Ÿ™‚

    Have an interesting question I can’t get any documentation or clear answer on. We’ve got an interesting scenario where we had a CA Root, and two subordinate CA’s (We’ll call SubCA1 and SubCA2) – but only one of the subs (SubCA1) was auto-issuing computer Certs (AOVPN Device Tunnel).

    AOVPN was pointed to using the Subordinate CA (Set-VpnAuthProtocol -RootCertificateNameToAccept $RootCACert -PassThru) which was fine – however someone since fixed our second Subordinate CA and I’m now seeing certs randomly issued from SubCA1 or SubCA2 which has become a problem – given AOVPN only looks at SubCA1.

    So here’s my question – if I were to set AOVPN to accept the Root CA’s cert (Instead of SubCA1/2) – does that mean it will also accept certs from SubCA1/2 as well as the Root CA? I couldn’t find any clarity or documentation around this.

    Alternatively – if it has to be pointed to a specific SubCA – can it be pointed to more than one? I couldn’t find any powershell examples or references where this was done – which leads me to think it’s not possible.

    If neither of the above are possible – that leads me to think my only possible answer is to ensure that a certificate is issued from a specific CA to each machine. Thoughts?

    • You can safely change the root certificate accepted to be the root and not an issuing CA, and all subordinate CAs under that root will be allowed to authenticate. That’s actually the best practice designed to avoid scenarios like this. ๐Ÿ™‚

      • Just on this, we are currently running Windows 2019 with the most up-to-date version. We have 1 offline root and two sub ca’s, we have the RootCACert pointing at our root cert and our sub CA’s issuing client certs, all is working fine…With the exception of revocation, i have done all of the above and also referred to the MS page on this but no joy. if i export the certificate from the client and copy it to the vpn server using the “.\certutil.exe -f -urlfetch -verify C:\NAMEOFCERT.cer” i can see that the certificate is revoked, but it is still able to connect to the server, restarts and everything. Is revocation supported in the offline root scenario?

      • Have you tried deleting the CRL cache on the VPN server?

        VPN Server: certutil.exe -urlcache * delete
        Issuing CA: certutil.exe -setreg chain\ChainCacheResyncFiletime @now

        Try that and see if it works. ๐Ÿ™‚

  7. Jane

     /  November 4, 2020

    Typo in the command to create the reg key above, although it appears correctly in the screenshot; the ‘2’ in IKEV2 is missing.

    • Jane

       /  November 4, 2020

      Actually, belay this; it appears properly in Chrome, but not it IE. Sorry about that…

    • Not sure what you are seeing, but it looks good to me. I copied/pasted on a test machine to validate just now too. ๐Ÿ™‚

  8. James

     /  January 18, 2021

    Many thanks for the guide it was very useful.

    I have added the registry setting and powershell commands, with my subordinate as the rootcacert

    when i run “certutil -f -urlfetch -verify certificate.cer” it show as revoked.

    but i am still able to connect with the certificate.

    I have done

    certutil.exe -urlcache * delete

    but the below errors with “expected at least 2 args, received 1
    certutil.exe -setreg chain\ChainCacheResyncFiletime @now

    I am on the latest version of server 2019 and am running two tier PKI.

    any help would be appreciated

    many thanks

    • Be sure to run the command “certutil.exe -setreg chain\ChainCacheResyncFiletime @now” from a command window (cmd.exe), not in a PowerShell window. Also, this command is run on the issuing CA server, just to be perfectly clear.

      Let me know if that helps!

  9. Simon Quist Erichstrup

     /  March 18, 2021

    Hi Richard,

    Another thought in regards of effectively prohibiting a Computer (device tunnel) from connecting.

    Though I read somewhere that Static IP Pool addressing is recommended because RRAS VPN does not make use/support DHCP options in any case, I was wondering if lease and reservation still works?

    If so, it may be possible to reserve a specific computers MAC and assign a bogus IP address?

    • Lease reservation times can be shortened, but they affect all clients on the VPN server because the VPN server leases the addresses from DHCP, not the client. You can’t do MAC address assignments because, again, the VPN server owns all the DHCP addresses, not the clients.

  10. Francesco F.

     /  July 6, 2021

    Hi Richard, many thanks for your guides!
    My clients are connected with AlwaysOn VPN device tunnel, I have my CRL published and reachable through internet.
    For security reason, I’m planning to remove CRL internet publication, it will be reachable only from internal networks.
    I have to concern about this? There is any issue related?
    Thanks in advance!

    • There’s no requirement to publish your internal, private PKI’s CRL to the Internet *unless* you are using internal issued TLS/SSL certificates for public-facing sites. The CRL does not need to be accessible externally for IKEv2.

  11. Arturas

     /  December 13, 2021

    Hi Richard, we have a strange situation. We have user and device tunnel in out setup. User tunnel is running on SSTP and Device tunnel is running on IKEv2. From time to time we get this “revocation server was offline” error. Our PKI is available both internally and externally. Device tunnel has a route to PKI server URL configured. My assumption is – device tunnel gets connected, because it uses internet to access revocation list server. Once Device tunnel is up – internal DNS comes into play. So now PKI address is resolved to internal IP, but it seems that for some reason it fails to reach it and user tunnel does not connect. Maybe you have seen this before? Could it be that device tunnel fails right after login? I’ve tried to provoke the error by stopping internal PKI website and trying to reconnect to User tunnel – but it connected without any issue. Is there some kind of interval when revocation list server is being checked?

  1. Always On VPN Device Tunnel Operation and Best Practices | Richard M. Hicks Consulting, Inc.
  2. Always On VPN Device Tunnel Only Deployment Considerations | Richard M. Hicks Consulting, Inc.
  3. Always On VPN Device Tunnel Status Indicator | Richard M. Hicks Consulting, Inc.

Leave a Reply to Richard M. HicksCancel reply