Recently 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
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
Simon
/ June 24, 2019This 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.
Richard M. Hicks
/ June 24, 2019It 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. 😉
John
/ July 16, 2019Hi 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
Richard M. Hicks
/ July 17, 2019That’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, 2019Hi 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.
Richard M. Hicks
/ November 13, 2019I 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. :/
Jason Jones
/ October 22, 2019Documented now: https://docs.microsoft.com/en-us/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/always-on-vpn-adv-options#blocking-vpn-clients-that-use-revoked-certificates
Richard M. Hicks
/ October 22, 2019Thanks Jason! 🙂
Dirk Rober
/ January 2, 2020The link for “PowerShell Script to Configure RootCertificateNameToAccept on GitHub” does not seem to work anymore. Can you point me to a working location?
Richard M. Hicks
/ January 2, 2020Thanks for the heads-up! The link is fixed now. 🙂
Gavin Ashton
/ April 1, 2020Is 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.
Richard M. Hicks
/ April 1, 2020No. 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. :/
Gavin Ashton
/ April 1, 2020Ok, 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!
Richard M. Hicks
/ April 1, 2020Thanks 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.
Stefan Hattrell
/ April 6, 2020Hey 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!
Richard M. Hicks
/ April 6, 2020Has RRAS been installed? If so, has VPN been configured?
Stefan Hattrell
/ April 6, 2020Ah! Figured it out. I hadn’t actually enabled machine certificate authentication as a method…
BWorrall
/ May 24, 2020Hey 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?
Richard M. Hicks
/ May 25, 2020You 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. 🙂
johncouzins
/ October 12, 2020Just 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?
Richard M. Hicks
/ October 16, 2020Have 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. 🙂
Jane
/ November 4, 2020Typo 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, 2020Actually, belay this; it appears properly in Chrome, but not it IE. Sorry about that…
Richard M. Hicks
/ November 6, 2020Interesting! Thanks for the tip. I’ll investigate and see what’s up for sure. 🙂
Richard M. Hicks
/ November 6, 2020Not sure what you are seeing, but it looks good to me. I copied/pasted on a test machine to validate just now too. 🙂
James
/ January 18, 2021Many 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
Richard M. Hicks
/ January 18, 2021Be 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!
Simon Quist Erichstrup
/ March 18, 2021Hi 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?
Richard M. Hicks
/ March 22, 2021Lease 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.
Francesco F.
/ July 6, 2021Hi 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!
Richard M. Hicks
/ July 6, 2021There’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.
Arturas
/ December 13, 2021Hi 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?
Richard M. Hicks
/ December 13, 2021So you’re getting this error for the user tunnel, not the device tunnel, correct? Also, are you using a public certificate for the SSTP connection?
Artūras
/ December 14, 2021Yes for SSTP user tunnel. We are using Internally issues certificates for VPN servers
Richard M. Hicks
/ December 15, 2021Got it. You’re right, the revocation URL is probably resolving to an internal private IP address but somehow that isn’t reachable for some reason. I would suggest using a public CA certificate just so you don’t have to worry about things like this. They are cheap (even free!) and work much more reliably for SSTP. 🙂
https://directaccess.richardhicks.com/2021/10/04/always-on-vpn-sstp-with-lets-encrypt-certificates/