When configuring a Windows Routing and Remote Access Service (RRAS) server to support Internet Key Exchange version 2 (IKEv2) VPN connections, it is essential for the administrator to define the root certification authority for which to accept IPsec security associations (SAs). Without defining this setting, the VPN server will accept a device certificate issued by any root certification authority defined in the Trusted Root Certification Authorities store. Details about configuring IKEv2 security and defining the root certification authority can be found here.
Multiple Root Certificates
Administrators may find that when they try to define a specific root certification authority, the setting may not be implemented as expected. This commonly occurs when there is more than one root certificate in the Trusted Root Certification Authorities store for the same PKI.
Certificate Selection
When running the PowerShell command Set-VpnAuthProtocol to define the root certification authority, PowerShell may ignore the administrator-defined certificate and choose a different one, as shown here. This will result in failed IPsec VPN connections from Windows 10 Always On VPN clients using IKEv2.
Certificate Publishing
This issue can occur when root certification authority certificates are published using Active Directory group policy. It appears that Windows prefers Active Directory group policy published certificates over those published directly in the Certification Authorities Container in Active Directory. To resolve this issue, remove any group policy objects that are publishing root certification authority certificates and ensure those root certificates are published in the Certification Authorities container in Active Directory.
PowerShell Script
A PowerShell script to configure this setting that can be found in my Always On VPN GitHub repository here. I have updated this script to validate the defined root certification authority certificate and warn the user if it does not match.
Additional Information
Set-Ikev2VpnRootCertificate.ps1 PowerShell script on GitHub
Windows 10 Always On VPN IKEv2 Security Configuration
Windows 10 Always On VPN IKEv2 Load Balancing and NAT
Windows 10 Always On VPN IKEv2 Features and Limitations
Corey Zamara
/ November 25, 2021Microsoft really needs to come up with a way to address this – I just went through this headache and have no idea why it kept reverting until I stumbled on this article.
Richard M. Hicks
/ November 29, 2021It’s really stupid, isn’t it! If I, the administrator, want to configure a specific certificate it should respect that! Terribly frustrating for sure. FYI, I have a script to configure this and added a check to warn the administrator if the configuration changes after restarting the service. 🙂
https://github.com/richardhicks/aovpn/blob/master/Set-IKEv2VpnRootCertificate.ps1
Jason
/ December 21, 2021Is it possible to specify two different root CA’s with the set-vpnauthprotocol command? I’m working with someone who is changing root CA and this setting is currently pointing at the CA to be decommissioned, but a transition period is needed where a cert from either CA would be valid to provide VPN authentication.
Richard M. Hicks
/ December 21, 2021Unfortunately, no. You’ll have to remove this restriction during the transition, then re-enable it later after all of your clients are migrated. Not ideal, I know. :/
bueschu
/ July 13, 2023We are using AoV User Tunnel (Ikev2 / SSTP)only and plan to implement a new CA root certifificatee to include Sha256. So we will have 2 root certificates, the old and the new one. We plan to implement the new root CA into the vpn-user profile as an additional one.
So we will soon have vpn-user using certifcates referencing the new root certifcate and in parallel there are still the old ones.
Do you think we ran into a problem with this scenario?
Richard M. Hicks
/ July 13, 2023Not if you plan carefully. 🙂 You’ll need to make sure you get the new certificates delivered to all of your client devices. After that you can switch the VPN settings.
bueschu
/ July 25, 2023thank you for clarifying this issue
bueschu
/ September 26, 2023When we use AoV with Conditional Access we have to define DeviceCompliance including the IssuerHash of the issuing CA of the User AoV root CA. How can we configure multiple IssuserHashes during the migration from the old to the new CA.
true
true
1.3.6.1.5.5.7.3.2
xydssds…….
Richard M. Hicks
/ September 26, 2023According to the CSP it accepts a comma-separated list of issuer hashes. With that you should be able to include both your old and new certificates.
https://learn.microsoft.com/en-us/windows/client-management/mdm/vpnv2-csp#deviceprofilenamedevicecompliancessoissuerhash
bueschu
/ September 26, 2023I tried that but it did not work. There is only ony issuer hash in the rasphone.bpk listed and the vpn-connection is not setup afterwards (no certificate).
I think we have to follow your recommendation and plan the CA migration step by step so we don’t need multiple IssuserHashes.
Richard M. Hicks
/ September 26, 2023Interesting. The documentation may be incorrect then. :/
bueschu
/ September 26, 2023Many thanks for your help.