When deploying Windows 10 Always On VPN using Protected Extensible Authentication Protocol (PEAP) authentication with client certificates, administrators may find the VPN connection does not establish automatically. In this specific scenario the client is prompted to select a certificate to use to authenticate to the VPN server.
Multiple Certificates
This can occur when certificates from multiple Certification Authorities (CAs) are issued to the user that include the Client Authentication Enhanced Key Usage (EKU). When this happens, the user is forced to select the correct certificate to use for VPN authentication.
Clearly this is less than ideal, as it not only breaks the seamless and transparent nature of Always On VPN, the user may select the wrong certificate resulting in authentication failure. Ideally the client should be configured to select the correct certificate without user interaction.
Certificate Selection
Follow the steps below to configure automatic certificate selection for VPN authentication.
- On a VPN client, right-click the Always On VPN connection and choose Properties.
- Select the Security tab.
- In the Authentication section click Properties below Use Extensible Authentication Protocol (EAP).
- In the Select Authentication Method section click Configure.
- In the When connecting section click Advanced.
- Check the box next to Certificate Issuer.
- Select the root CA used to issue client authentication certificates for VPN authentication.
- Click Ok four times to save the configuration.
Once complete, export the EAP configuration to XML from the VPN client and paste the new settings in Intune or in your custom ProfileXML.
Certificate Purpose
By default, a client certificate requires only the Client Authentication EKU to establish a VPN connection. In some cases, this may not be desirable. For example, consider a deployment where Client Authentication certificates are issued to all users for Wi-Fi authentication. Depending on the Network Policy Server (NPS) configuration, these certificates may also be used to authenticate to the VPN.
VPN Specific Certificate
Follow the steps below to create a user authentication certificate template to be used exclusively for VPN authentication.
Certificate Template
- On the CA server, open the Certificate Templates management console (certtmpl.msc).
- Right-click the certificate template configured for VPN authentication and choose Properties.
- Select the Extension tab.
- Highlight Application Policies and click Edit.
- Click Add.
- Click New.
- Enter a descriptive name for the new application policy.
- Copy the Object identifier for later use and click Ok four times to save the configuration.
- If certificate autoenrollment is configured and the certificate is already provisioned to users, right-click the certificate template and choose Reenroll All Certificate holders.
Client Configuration
- On the VPN client, follow the steps outlined previously to configure certificate selection.
- In addition to choosing a certificate issuer, select Extended Key Usage (EKU).
- Uncheck All Purpose.
- Select Client Authentication and the following EKUs.
- Click Add.
- Click Add once more.
- Enter the name of the custom EKU policy created previously.
- Enter the custom EKU object identifier copied previously from the custom policy.
- Click Ok twice.
- Uncheck AnyPurpose and the following EKUs.
- Click Ok four times to save the configuration.
Once complete, export the EAP configuration to XML from the VPN client and paste the new settings in Intune or in your custom ProfileXML.
Additional Information
Windows 10 Always On VPN Clients Prompted for Authentication when Accessing Internal Resources
Andy Chips
/ May 28, 2019Thanks Richard. Another superb article. This problem had me banging my head repeatedly against the wall until you pointed me in the right direction.
Another symptom of this issue is the VPN connection reporting “This connection is already being dialed”.
Richard M. Hicks
/ May 28, 2019Thanks Andy! 🙂
Andy Chips
/ May 19, 2022Hi RIchard,
Not sure if this question directly relates to this topic, but it’s close.
We are about to change our default AD UPN from @companyA.com to @companyB.com. This will obviously break existing AO user certificates. Can I just click Reenroll All Certificate Holders for the existing certificate, or should I create a new one/duplicate it?
Richard M. Hicks
/ May 19, 2022I think that if you update your user’s UPN and re-enroll all certificate holders that should work. The new certificate issued will include whatever their new UPN is at that point.
Andy Chips
/ May 24, 2022With reference to Richard’s comment above (I don’t seem to be able to reply in context):
Richard M. Hicks / May 19, 2022
I think that if you update your user’s UPN and re-enroll all certificate holders that should work. The new certificate issued will include whatever their new UPN is at that point.
This worked perfectly, thank you.
Richard M. Hicks
/ May 24, 2022Great to hear! 🙂
Karsten Hentrup
/ May 29, 2019Nice article, thanks for sharing. I saw this problem in several SSTP + AO VPN installations/configurations. Very helpful and very hidden parameter!
🙂
Greets, Karsten…
Colin
/ June 19, 2019Richard, There seems to be problems with Windows 10 1903 connecting to AOVPN.
Can you confirm? Fully patched 1903, cannot connect to AOVPN but 1803-1809 seem to connect fine still. Same profiles, same settings etc.. all deployed cookie cutter from SCCM.
Richard M. Hicks
/ June 19, 2019No issues to report in my Always On VPN testing with Windows 10 1903.
Colin
/ June 19, 2019I confirmed others experiencing the same problems on technet forums.
Are you doing a clean 1903 or upgraded from 1809 to 1903. I am an upgrade to 1903
Richard M. Hicks
/ June 19, 2019Clean install. Haven’t tested an upgrade yet, but will do so soon.
Matthew
/ October 9, 2019Hello, we have an intermittent issue with our Always on VPN user tunnels. We get “a certificate could not be found that can be used with this extensible authentication protocol” errors. The the working users and the non nonworking users were all set up the same.
If I check the users Client Authentication cert in their personal store it all looks good, and the certification path is OK.
If I delete the cert, reboot so it picks up a new one, then it works fine.
Is there anyway to get enhanced debugging on cert selection?
Kind regards
Matt
Richard M. Hicks
/ October 10, 2019Very strange! I’d suggest enabling the CAPI2 operational log and having a look there.
Matthew Bristow
/ October 10, 2019OK I’ll try that. It’s annoying as we can’t replicate it. We are using roaming profiles for hot desking, which may come into play. In addition we have 3 internal rootca certs, each time a new one has been generated the old one has been kept. All 3 are being pushed by both AD and by GPO, hence we see six rootca entries in the certificate selection dialogue. I have ticked all of them. But I was wondering if that might be complicating things. Is it worth UN-ticking “simple cert selection”?
Richard M. Hicks
/ October 10, 2019You can certainly try that and see if the experience changes.
Eric
/ April 6, 2020I stumbled on this comment with the same problem. I checked the CAPI2 log (thanks for that!) and discovered the private key for the user certificate is missing. Sure enough, try the export and you get a specific ‘key is missing’ error. I haven’t yet figured out why the user cert key disappears. I don’t see any roaming profile/roaming credential stuff setup… I did set a registry key (google ‘df9d8cd0-1501-11d1-8c7a-00c04fc297eb’) to support connecting remotely by username/password first, perhaps that has an impact… Anyway, still plugging away unless someone has any suggestions? Thanks!
Matthew
/ April 7, 2020Hi Eric, our problems were definitely caused by roaming profiles between TPM and non TPM machines (the private key can’t leave the TPM machine), we moved to using the software KSP… and it went away. TBH I’d rather kill off roaming profiles :-/
0fflineDocs
/ June 8, 2020Hi Richard,
Thanks a lot for an excellent and informative post.
Ci
/ June 25, 2020I have a physical smartcard with the user certificate on it.
The VPN fails with “A certificate could not be found that can be used with this Extensible Authentication”.
But if I look in certmgr.msc I have one user cert with Client Authentication EKU.
Is it possible to have seamless User VPN Tunnel established with physical smartcard (PIN protected)
Richard M. Hicks
/ June 29, 2020I don’t think so. I believe it should still work though, but you’ll most likely be prompted for a pin to access the private key on the smart card.
MrScholz
/ January 8, 2024Hello Richard,
I have been tasked with deploying Always-on VPN, and have reached the stage of creating a client VM and installing the certificates.
I have joined the machine to the domain, I have made certain the computer is a member of the VPN Computers, that the user is a member of VPN Users, and the SmartCard from the host machine is connected to the VM. I have checked gpresult report and seen that Autoenrollment and Turn On Script Execution policies are being applied.
The Certificate Manager has NO certificates under Current User Personal, and a forced gpupdate and restart do not resolve the issue.
Please help!
Richard M. Hicks
/ January 9, 2024There are many things that could prevent a certificate from being deployed to the endpoint. A good test is to try to enroll for the certificate manually. If you can do that, you should be able to enroll automatically. If not, you’ll receive an error of some sort. After you resolve that it should work.
Mr. Scholz
/ January 10, 2024I have successfully deployed the certificate, and proceeded with the rest of the steps of deployment. When it came time to connect, I am receiving an error message of “IKE authentication credentials are unacceptable.”
Richard M. Hicks
/ January 10, 2024There are many things that can cause this error. I’d suggest starting here.
https://directaccess.richardhicks.com/2021/12/13/always-on-vpn-error-13801/
Let me know if that helps!