Always On VPN and Cloud PKI for Intune Error 853

Microsoft Cloud PKI for Intune is a PKI-as-a-Service offering that allows organizations to issue and manage digital certificates without on-premises infrastructure. Certificates are excellent phishing-resistant credentials that are well-suited for applications requiring strong authentication, such as secure remote access with Always On VPN. However, administrators may encounter errors when attempting to authenticate users or devices using certificates issued by Cloud PKI for Intune.

Error 853

After publishing certificates with Cloud PKI for Intune and configuring the on-premises Always On VPN infrastructure to support this, administrators will find that the Always On VPN connection fails to connect. Attempts to manually start the connection result in the following error message.

“The remote access connection completed, but authentication failed because the certificate that authenticates the client to the server is not valid. Ensure the certificate used for authentication is valid.”

In the event log on the Windows client, you’ll find an event ID 20227 from the RasClient source that includes the following error message.

“The user <domain>\<user> dialed a connection named <VPN connection name> which has failed. The error code returned on failure is 853.”

Error 853 (ERROR_EAP_USER_CERT_INVALID) indicates the user certificate is invalid.

Certificate

Upon further investigation, the certificate shows no issues, is valid, is trusted, and has a private key.

NPS

Looking at the event log on the Network Policy Server (NPS), you’ll find a corresponding event ID 6273 from the Microsoft Windows security auditing source that includes the following error message.

“Network Policy Server denied access to a user.”

Looking at the authentication details section of this event log entry yields the following important clue.

Reason Code: 258
Reason: The revocation function was unable to check revocation for the certificate.

Failed Revocation Check

Since the NPS server indicates that it rejected the authentication request because it could not perform a revocation check, let’s bring the user authentication certificate to the NPS server and perform some tests.

Export Certificate

Open the user certificate store (certmgr.msc) on the client and expand Personal > Certificates. Right-click on the certificate in question and choose All Tasks > Export. Export the certificate only (not the private key) and copy the file to the NPS server.

Verify Certificate

Open a PowerShell or command window on the NPS server and run the following command to validate the certificate.

certutil.exe -verify -urlfetch <path to exported certificate>

For example.

certutil.exe -verify -urlfecth .\rdeckard.cer

The command generates a lot of output, but if you look at the very end of the data stream, you’ll see two interesting items.

  • Revocation check skipped – no revocation information available
  • Leaf certificate revocation check passed

Based on this information the user certificate (the leaf certificate) passed a revocation check. However, it would appear that another certificate in the chain does not include revocation information. Since there is only a root and issuing CA in the chain, and root certificates don’t include revocation information because they are the self-signed root of trust, it would appear that revocation information is missing from the issuing CA certificate.

We can confirm this by scrolling up in the previous command’s output to where the verification of the issuing CA certificate takes place. Here, you’ll see that the issuing CA certificate is missing CDP (CRL Distribution Point) information.

When NPS attempts to validate the certificate and the certificate chain, it expects to find CDP information, which it will use to check if the issuing CA certificate has been revoked. The revocation check fails without this information, and the authentication request is rejected.

Design Error?

Missing CDP information is not unusual for end-entity (leaf) certificates when they are short-lived. An example is Entra ID conditional access certificates, which do not include CDP information by design. However, I expect this information to be listed on an issuing CA certificate. Why it’s not there, I’m not sure. I’ll investigate this in more depth and report on anything I learn that’s new.

Workaround

To move forward using Cloud PKI for Intune certificates with Always On VPN, administrators must implement the following registry setting on all NPS servers handling authentication requests for Always On VPN servers.

Key = HKLM\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13
Name = IgnoreNoRevocationCheck
Type = DWORD
Value = 1

To implement this change using PowerShell, open an elevated PowerShell command window and run the following command.

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13\’ -Name IgnoreNoRevocationCheck -PropertyType DWORD -Value 1 -Force

Once complete, restart the NPS server for the changes to take effect.

Additional Information

Cloud PKI for Microsoft Intune

Cloud PKI for Microsoft Intune and Active Directory

Cloud PKI for Microsoft Intune and Certificate Templates

Strong Certificate Mapping for Microsoft Intune PKCS and SCEP Certificates

Troubleshooting Intune Failed PKCS Request

Cloud PKI for Microsoft Intune SCEP URL

Delete A Cloud PKI for Microsoft Intune Certificate Authority

Cloud PKI for Microsoft Intune on RunAs Radio Podcast

Mastering Certificates with Microsoft Intune Online Training

Always On VPN Windows Server 2025 Binding Handle is Invalid Error

Microsoft released Windows Server 2025 late last year. I’ve been doing extensive testing with the Routing and Remote Access (RRAS) role, commonly deployed to support Always On VPN client connections. I heavily use automation to deploy VPN servers in my lab and for large customer deployments, and after deploying some new Windows Server 2025 machines, I encountered the “binding handle is invalid” error message when running specific commands.

VPN Ports

By default, Windows Server RRAS enables IKEv2 for Remote Access (RAS) and SSTP for RAS and Routing. Each is provisioned with 128 ports. Often, these settings are updated because there are not enough ports to support expected concurrent connections. Also, SSTP should not be enabled for Routing as it is not required, and PPPoE is enabled for Routing, which is also not required. The best practice is to disable any protocols and services that are not being used.

Although updating these settings can be updated in the GUI (rrasmgmt.msc), automating these changes requires command line configuration.

Netsh

Here’s the command to configure additional SSTP ports and disable Routing using netsh.exe.

netsh.exe ras set wanports device = “WAN Miniport (SSTP)” rasinonly = enabled ddinout = disabled ddoutonly = disabled maxports = 500

However, running this command returns the following error message.

“The binding handle is invalid.”

PowerShell

You might be wondering why we don’t use PowerShell for these tasks. Sadly, not all these settings are exposed via PowerShell. For example, with the native Set-VpnServerConfiguration PowerShell command, you can set the number of ports for IKEv2, SSTP, L2TP, and GRE. However, you cannot turn these protocols on or off entirely as you can with netsh.exe commands.

Here’s an example of setting up VPN server port configuration using PowerShell.

Set-VpnServerConfiguration -SstpPorts 500 -Ikev2Ports 500 -PassThru

Note: You must restart the server (not just the RemoteAccess service) when increasing the number of ports beyond the default setting of 128.

Set-VpnServerConfiguration does not support configuration for PPTP. However, PPTP is disabled by default on Windows Server 2025.

Backup and Restore

This issue will also impede the ability to back and restore the RRAS configuration using netsh.exe. You can back up the RRAS configuration by running the following command.

netsh.exe ras dump | Out-File rasconfig.txt -Encoding ascii

You can restore the configuration by running the following command.

netsh.exe exec .\rasconfig.txt

However, you will receive “binding handle is invalid” error when running this command.

AovpnTools

Be advised that the following functions in my AovpnTools PowerShell module use netsh.exe commands that will return the “binding handle is invalid” error message when configuring Windows Server 2025 servers.

Workaround

Until Microsoft resolves this issue, administrators must use a combination of the native PowerShell commands and manual configuration using the Routing and Remote Access management console (rrasmgmt.msc) to implement these settings changes. When backing up and restoring the RRAS configuration, additional configuration will be required after configuration import to ensure the VPN server port configuration is configured correctly.

Additional Information

Always On VPN PowerShell Module on GitHub

Always On VPN Ask Me Anything (AMA) January 2025

It’s that time again! I realize it’s been a while since we’ve had one of these events. However, it’s a new year and we’re planning to get together again on Tuesday, January 21, 2025, at 10:00 AM PST (UTC-7).

Do you have questions about Always On VPN? Are you having a specific issue you can’t figure out? Would you like more information about configuration options? Here’s your chance to get your questions answered! Register now and join the session for an opportunity to ask me anything (AMA!) about Microsoft Windows Always On VPN and related technologies.

The AMA will be an open forum session where we can all talk shop about Always On VPN. It’s a great chance to learn new things and share experiences with your peers. We’ll discuss known issues and limitations, best practices, and more. I’m planning to have some special guests as well, so be sure to join us!

Everyone is welcome. Don’t miss out on this excellent opportunity to connect and learn. Register now!

Can’t make the session? Register anyway, and I’ll send you the link to the recording as soon as it is available!