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

Microsoft Intune Cloud PKI and Certificate Templates

Microsoft recently announced the general availability of its new PKI-as-a-Service platform called Microsoft Intune Cloud PKI. With Intune Cloud PKI, administrators create certification authorities (CAs) to issue and manage user and device authentication certificates for Intune-managed endpoints. Cloud PKI also provides hosted Authority Information Access (AIA) and Certificate Revocation List (CRL) Distribution Point (CDP) services, in addition to Simple Certificate Enrollment Protocol (SCEP) service, so administrators do not have to deploy on-premises infrastructure to take advantage of certificate-based authentication.

Certificate Templates

After deploying your Intune Cloud PKI root and issuing CAs, you may wonder where to find the associated certificate templates. If you are familiar with traditional on-premises Active Directory Certificate Services (AD CS) implementations, this is how you define the purpose, key policy, security parameters, and lifetime of the certificate issued using that template. However, Intune Cloud PKI does not use certificate templates in the traditional way many administrators are familiar with.

Note: Microsoft may introduce support for certificate templates for Intune Cloud PKI in the future. However, it is not supported at the time of this writing.

SCEP Profile

Administrators define certificate policies and security parameters using Intune’s SCEP device configuration profile instead of certificate templates. In essence, the SCEP profile functions as the certificate template. With the Intune device configuration profile, administrators can define the following settings.

Certificate Type

The certificate type can be either a user or a device. Intune Cloud PKI can issue certificates for either or both, as required.

Subject Name (User)

The subject name is unimportant for user authentication certificates because the User Principal Name (UPN) defined in the Subject Alternative Name field is used to authenticate the user. In this field, the administrator can use whatever they like. However, it’s common to use the username here. Avoid using the email attribute here because there’s no guarantee that every user will have this defined on the Active Directory (AD) user object.

Subject Name (Device)

Administrators should supply the device’s fully qualified domain name (FQDN) for device authentication certificates in the subject name field. For hybrid Entra joined devices, administrators can use the {{FullyQualifiedDomainName}} variable. For native Entra-joined devices, you can use {{DeviceName}} and append your DNS suffix, for example, {{DeviceName}}.corp.example.net.

Note: Intune supports numerous variables to populate fields for certificates. You can find a list of supported variables in the following locations.

User Certificate Variables: https://learn.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep#create-a-scep-certificate-profile:~:text=Manager%20blog%20post.-,User%20certificate%20type,-Use%20the%20text

Device Certificate Variables: https://learn.microsoft.com/en-us/mem/intune/protect/certificates-profile-scep#create-a-scep-certificate-profile:~:text=on%20the%20device.-,Device%20certificate%20type,-Format%20options%20for

Subject Alternative Name (User)

The Subject Alternative Name (SAN) field for user authentication certificates should be populated with the User Principal Name (UPN) value. Ensure this value is appropriately configured internally and supports sign-in to AD.

Subject Alternative Name (Device)

The SAN field for device authentication certificates should be populated with the device’s FQDN. Follow the guidance for device subject names covered previously.

Certificate Validity Period

This field allows the administrator to define the certificate’s validity period. The best practice is to limit the lifetime to no more than one year. A shorter lifetime is recommended for certificates not backed by a Trusted Platform Module (TPM).

Key Storage Provider

This value is critical to ensuring integrity for issued user and device authentication certificates. The best practice is to select Enroll to Trusted Platform Module (TPM) KSP, otherwise fail. However, if you must issue certificates to endpoints without a TPM (e.g., legacy devices, virtual machines, etc.), consider a separate profile with a shorter certificate lifetime to limit exposure.

Key Usage

Digital signature and Key encipherment are required for user and device authentication certificates.

Key Size

The 2048-bit key size is the minimum recommended value for certificates with RSA keys. Using 4096-bit is not recommended for end-entity certificates and can potentially cause conflicts in some cases. Intune Cloud PKI does not support the 1024-bit key size.

Hash Algorithm

SHA-2 is the best practice for the hash algorithm. SHA-1 has been deprecated and should not be used.

Root Certificate

Select the Cloud PKI root CA certificate.

Extended Key Usage

The minimum requirement for user and device authentication certificates is Client Authentication (1.3.6.1.5.5.7.3.2).

Renewal Threshold

This value specifies at what point the certificate can be renewed. 20% is commonly used for certificates with a one-year lifetime.

SCEP Server URLs

This value can be found on the configuration properties page of your Cloud PKI issuing CA. The URI will include a variable in the URL. The variable is there by design. Copy and paste this URL exactly as displayed in the SCEP URL field.

Training

Are you interested in learning more about issuing and managing certificates with Microsoft Intune? Would you like to know how to securely and optimally implement PKCS and SCEP infrastructure on-premises? Do you want more details about deploying and managing Microsoft Intune Cloud PKI? Register now for my upcoming three-day live Certificates and Intune Masterclass training event at the ViaMonstra online training academy. We’ll deep-dive into all aspects of certificate management using Intune with on-premises AD CS and Intune Cloud PKI. I’ll be sharing many advanced techniques for adequately securing your certificate infrastructure. Space is limited, so register now!

Additional Information

Mastering Certificates with Intune Training Course

Microsoft Intune Cloud PKI Overview

Microsoft Intune Cloud PKI and Active Directory

Microsoft Intune Certificate Connector Failure

Microsoft Intune Certificate Connector Configuration Failed

Microsoft Intune Certificate Connector Configuration Failure

Microsoft Intune Certificate Connector Service Account and PKCS