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

November Microsoft Security Updates and AD CS

As I do each month on Patch Tuesday, I look through the list of published vulnerabilities in search of things that might interest Always On VPN Administrators. Frequently there are updates for things like Routing and Remote Access Service (RRAS) or various VPN protocols. The good news is that the November 2024 security updates include NO such vulnerabilities! However, a vulnerability has been disclosed that affects Active Directory Certificate Services (AD CS) on which Always On VPN often relies on for user and device authentication.

Certificate Templates

AD CS Enterprise certificate authorities are closely integrated with Active Directory and use certificate templates that administrators can publish for users and devices to enroll. These templates control properties of the issued certificates, such as the subject name, usage, key length, enrollment policies, and much more. There are several different template versions available, versions 1 through 4. Version 1 templates are legacy templates that don’t provide many capabilities. Later versions include more features and capabilities.

CVE-2024-49019

The November 2024 Microsoft security updates include CVE-2024-49019, a privilege escalation vulnerability recently discovered in AD CS. Specifically, this vulnerability affects only legacy schema version 1 certificate templates published on a certificate authority (CA) server that include the option to supply the subject name in the certificate request. A typical example of this would be the default Web Server template.

Exploitation

The Web Server template does not include the Client Authentication Enhanced Key Usage (EKU) by default, which is required to authenticate to Active Directory. However, this vulnerability allows an attacker with enrollment privileges on this template to supply additional EKUs in the request and the certificate issued will include those capabilities. This allows a non-privileged attacker to quickly elevate to a domain or enterprise administrator by supplying a known administrator’s User Principal Name (UPN) along with the Client Authentication EKU in the certificate request. As version 1 templates cannot enforce CA manager approval for enrollment, an attacker can easily leverage this vulnerability if permissions allow, leading to complete domain compromise.

Note: This applies to any schema version 1 certificate template published with the subject name supplied in the request, not just the Web Server template.

Complications

Making matters worse, the Web Server template is one of the default certificate templates published automatically when a Windows Server CA is deployed. The best practice is to disable the publishing of any certificate templates by default when a new CA is provisioned. However, it requires additional configuration that is often overlooked. In addition, many administrators use overly broad enrollment permissions for this template, such as Domain Users, Domain Computers, or Authenticated Users, further broadening the attack surface.

Mitigation

Administrators should update their CA servers as soon as possible. If you cannot deploy this update immediately, consider replacing any schema version 1 templates with version 2 templates, which are not vulnerable. Also, as best practice, ensure that any certificate templates that allow the subject name to be supplied in the request also requires CA manager approval or additional authorized signatures for enrollment.

Investigation

Administrators should review enrollment privileges for all published certificate templates to ensure the least privileged access. In addition, administrators should audit all valid certificates issued with schema version 1 certificate templates that allow the subject name to be supplied in the request immediately to look for indicators of compromise. Review issued certificates for unauthorized EKUs or unusual subject names, especially those with a UPN.

Additional Information

Microsoft November 2024 Security Updates

CVE-2024-49019 – AD CS Elevation of Privilege Vulnerability

EKUwu: Not Just Another AD CS ESC – TrustedSec

Delete A Cloud PKI for Intune Certificate Authority

Deleting an Always On VPN Device Tunnel

When Microsoft first introduced Cloud PKI for Intune, the solution did not allow administrators to delete a CA after it was created. As you are limited to just six Cloud PKI for Intune CAs, this was quite frustrating, especially during the testing and evaluation phase, where you may need to spin up a few instances before you decide on the features you need.

Are you interested in learning more about Cloud PKI for Intune? Register for my upcoming online training course, Mastering Certificates with Microsoft Intune. This three-day comprehensive, deep-dive course covers all aspects of issuing and managing certificates with Intune, including provisioning and managing Cloud PKI for Intune. Click here to learn more.

Delete Cloud PKI

Thankfully, Microsoft eventually realized this shortcoming and added this much needed feature a few months ago. However, removing an Intune Cloud PKI CA requires administrators to follow some specific steps to remove a CA successfully. Since Cloud PKI for Intune uses a two-tier deployment model, administrators must remove the issuing CA first and then the root CA if required.

Issuing CA

Follow the steps below to delete a Cloud PKI for Intune issuing CA.

Intune Policies

Be sure to delete any Intune device configuration policies relating to Cloud PKI for Intune before decommissioning a Cloud PKI for Intune CA. This includes trusted certificate policies, Wi-Fi policies, and VPN policies.

Pause CA

The first step of deleting a Cloud PKI for Intune CA is to pause the service. Pausing the service prevents new certificates from being issued while the administrator completes the remaining retirement tasks. Open the Intune portal (https://intune.microsoft.com), navigate to Tenant Administration > Cloud PKI, and click the CA to be deleted. Next, click Pause to pause the CA.

Revoke Certificates

Administrators must revoke all issued certificates before deleting the issuing CA. Click on any issued certificate to view its properties and then click the Revoke button, as shown here.

Complete this step for each certificate issued and active on the CA.

Note: It takes some time before the certificate status shows Revoked in the management console. Be patient!

Revoke CA Certificate

Once the administrator has revoked all issued certificates, click Revoke to revoke the issuing CA’s certificate.

Delete CA

Once the issuing CA certificate has been revoked the administrator will now have the option to delete the Cloud PKI for Intune issuing CA.

Root CA

After the administrator deletes the issuing CA, the root CA can be removed if necessary. Click on the root CA and click the Delete button.

Additional Information

Delete Microsoft Cloud PKI Certification Authority

Strong Certificate Mapping for Intune PKCS and SCEP Certificates

Microsoft Cloud PKI for Intune and Certificate Templates

Microsoft Cloud PKI for Intune and Active Directory

Microsoft Cloud PKI for Intune SCEP URL

Microsoft Cloud PKI for Intune on RunAs Radio