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
Recently I wrote about 
Once Windows 10 Always On VPN has been deployed in production, it may be necessary at some point for administrators to deny access to individual users or computers. Commonly this occurs when an employee is terminated or leaves the company, or if a device is lost, stolen, or otherwise compromised. Typically, this means that user accounts and computer accounts in Active Directory are disabled, and any issued certificates are revoked. However, additional steps may be required to disconnect current VPN sessions or prevent future remote connections.
