Always On VPN SSTP and 47-Day TLS Certificates

The Secure Socket Tunneling Protocol (SSTP) VPN protocol uses Transport Layer Security (TLS) encryption and HTTP transport over TCP port 443. SSTP is easy to configure and firewall-friendly, making it an excellent choice for the Always On VPN user tunnel. Security best practices dictate using a TLS certificate issued by a public Certification Authority (CA). Today, the maximum lifetime of a public TLS certificate is 398 days (approximately 1 year). Always On VPN administrators using SSTP are familiar with the process of renewing their SSTP certificate annually. However, that’s about to change.

47 Days

In April of this year, the CA/Browser Forum, a voluntary consortium of public CAs, browser vendors, and other industry stakeholders that develop and promote security standards and best practices for digital certificates and Public Key Infrastructure (PKI), adopted a measure reducing the current maximum lifetime of public TLS certificates to 47 days. This means Always On VPN administrators using public TLS certificates must eventually update their TLS certificates monthly.

Automation

Of course, no administrator in their right mind would want to renew SSTP certificates every month. Automating this process will be crucial to ensuring reliability and reducing management overhead. I’ll provide more details later in this post.

Why Is This Happening?

The industry has been trending toward shorter certificate lifetimes for a while now. In the old days, you could purchase a certificate valid for 5 years or more. Today, a one-year certificate is all you can get. Let’s Encrypt, a public CA that issues certificates for free, issues only 90-day lifetime certificates.

Advantages

The advantage of using short-lived certificates for public TLS certificates is that they improve security and provide agility for future changes. Public TLS certificates become less secure and trustworthy over time. The longer a certificate is valid, the less trustworthy it becomes and the longer the opportunity for an attacker to leverage a certificate for which the private key has been compromised.

Why 47 Days?

A 47-day maximum certificate lifetime allows administrators to rotate their certificates monthly (a maximum of 31 days plus some margin to resolve issues).

Not So Fast

The good news for Always On VPN administrators using SSTP with public TLS certificates is that they won’t have to worry about this immediately. The reduction in maximum certificate lifetime to 47 days takes place gradually over a few years.

  • Today, the maximum public TLS certificate lifetime is 398 days
  • On March 15, 2026, the maximum public TLS certificate lifetime will be reduced to 200 days
  • On March 15, 2027, the maximum public TLS certificate lifetime will be reduced to 100 days
  • On March 15, 2029, the maximum public TLS certificate lifetime will be reduced to 47 days

Let’s Encrypt

Over the years, I’ve deployed Always On VPN with SSTP for several customers using Let’s Encrypt TLS certificates. Let’s Encrypt is a pubic CA that issues certificates with a maximum lifetime of 90 days, so automating this task is essential. Let’s Encrypt supports ACME, a standard protocol for automating the issuance and renewal of TLS certificates, which makes automating TLS certificate installation and renewal a breeze.

Sample Script

I’ve published a sample PowerShell script demonstrating how to automate the enrollment process for Let’s Encrypt TLS certificates. It leverages the Posh-ACME PowerShell module and my AOVPNTools module to enroll and automatically install a TLS certificate for SSTP. This script will also work for DirectAccess. You can find the sample script here.

Note: My sample script demonstrates using the Cloudflare DNS plugin for Posh-ACME. Posh-ACME has plugins for many public DNS providers, which can be found here. Feel free to customize my script to meet your specific needs.

Act Now

Always On VPN administrators are advised to consider solutions to automate TLS certificate enrollment and renewal as soon as possible. If your public CA of choice doesn’t support some form of certificate automation like ACME, it’s time to find another provider.

Summary

Starting in March 2026, the maximum lifetime for public TLS certificates will be reduced gradually, reaching just 47 days by March 2029. Automation will no longer be optional for Always On VPN administrators using SSTP—it will be essential. Tools like the Posh-ACME PowerShell module provide a reliable solution to streamline certificate management and ensure uninterrupted connectivity. Now is the time to prepare for this industry shift by implementing automated certificate renewal solutions. If you’d like professional assistance with this task or simply want to learn more about your options, drop me a note via the contact page, and I’ll respond with more information.

Additional Information

TLS Certificate Lifetimes Will Officially Reduce to 47 Days – DigiCert

Posh-ACME PowerShell Module

Posh-ACME Documentation

Always On VPN Tools (AOVPNTools) PowerShell Module

Always On VPN Authentication Failure After February 2025 Security Update

Microsoft introduced changes to Windows domain controllers in the February 2025 security update that may result in authentication failures for Always On VPN user tunnel connections. If you suddenly find that all your Always On VPN user tunnel connections fail, additional changes may be required to resolve the issue.

Authentication Failure

Administrators may find that Always On VPN connections fail after applying the February 2025 Microsoft security updates. Specifically, users may receive the following warning message.

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

Error 853

Administrators will also find a corresponding event log entry with event ID 20227 from the RasClient source with the following error message.

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

NPS Events

The event log on the NPS server will also record event ID 6273 from the Microsoft Windows security auditing source with the following error message.

“Network Policy Server denied access to a user.”

The authentication details of the event include Reason Code 16 with the following reason.

“Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.”

DC Events

If the issue is related to changes implemented to domain controllers in the February 2025 security update, administrators will also find a corresponding event log entry on a domain controller with event ID 39 from the Kerberos-Key-Distribution-Center source with the following error message.

“The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a secure way (such as via explicit mapping, key trust mapping, or a SID). Such certificates should either be replaced or mapped directly to the user via explicit mapping.”

Root Cause

The above conditions indicate that a user attempted to authenticate to the VPN with a certificate that was not strongly mapped. Most likely, the certificate was issued using Microsoft Intune with SCEP or PKCS. This results from changes made to domain controllers in the February 2025 security update that requires certificates used for Active Directory authentication to be strongly mapped. Until now, domain controllers allowed access and only logged an event in the event log when a certificate did not include strong certificate mapping. The February 2025 security update now enforces strong certificate mapping, and authentication requests will fail without it.

Resolution

Administrators must issue new certificates that are strongly mapped to resolve this issue. For certificates issued with PKCS, changes are required on the Intune Certificate Connector server before re-issuing. For certificates issued with SCEP, changes to the device configuration policy are required. See the post Strong Certificate Mapping for Intune PKCS and SCEP Certificates for more details.

Workaround

Re-issuing certificates takes time. To restore connectivity immediately, administrators can implement the following registry settings on all domain controllers to switch back to audit mode and allow authentication without strong certificate mapping.

Key: HKLM:\SYSTEM\CurrentControlSet\Services\Kdc
Name: StrongCertificateBindingEnforcement
Type: DWORD
Value: 1

I recommend deploying this setting via GPO assigned to the Domain Controllers OU. However, you can also implement this change using PowerShell if necessary.

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\Kdc’ -Name ‘StrongCertificateBindingEnforcement’ -PropertyType DWORD -Value 1 -Force

Additional Information

Strong Certificate Mapping for Intune PKCS and SCEP Certificates

Strong Certificate Mapping Enforcement February 2025

Certificate-Based Authentication Changes and Always On VPN

Intune Strong Certificate Mapping Error

Strong Certificate Mapping Error with PKCS

Always On VPN Intermittent 13801 Error

Always On VPN error 13801 is common when establishing an IKEv2 VPN connection. Typically, the issue is related to a configuration error or a problem with certificate deployment. However, administrators may encounter the 13801, an IKE authentication error, intermittently. Configuration errors are binary. If there is a misconfiguration, IKEv2 never works at all. However, a configuration error seems unlikely since the connection works occasionally yet fails at other times.

Client Authentication

The minimum application policy (Enhanced Key Usage, or EKU) requirement for the device authentication certificate for IKEv2 is Client Authentication (1.3.6.1.5.5.7.3.2). When intermittent 13801 errors occur, administrators may find multiple certificates in the local computer certificate store with the Client Authentication EKU issued by different certificate authorities. Commonly, Intune-managed Windows devices may include several certificates with Client Authentication.

Certificate Selection

When Windows attempts to establish an Always On VPN IKEv2 connection, and there are multiple certificates in the local computer certificate with Client Authentication defined, Windows must choose one certificate to use for the connection. If Windows chooses incorrectly, you will receive the 13801 IKE authentication failure error. If Windows selects the right one, the connection succeeds.

Resolution

There are several ways to resolve this issue. The best way is to update the Always On VPN device authentication certificate to include the IP security IKE intermediate application policy (EKU). When Windows encounters multiple client authentication certificates in the local computer certificate store, it will prefer any certificate with the IP security IKE intermediate application policy for IKEv2 VPN connections. Including the IP security IKE intermediate application policy on the Always On VPN device authentication certificate ensures proper certificate selection when multiple client authentication certificates are present.

Note: This change must be made to the Intune certificate enrollment template when using Intune with PKCS or SCEP.

Certificate Template

To update an existing Always On VPN device authentication certificate to include the IP security IKE intermediate application policy, open the certificate templates management console (certtmpl.msc) and perform the following steps.

  1. Right-click the VPN device authentication certificate template and choose Properties.
  2. Select the Extensions tab.
  3. Click on Application Policies.
  4. Click Edit.
  5. Click Add.
  6. Select the IP security IKE intermediate application policy.
  7. Click Ok.
  8. Click Ok.
  9. Click Ok.

Once complete, any certificates issued after this change is applied will now include the IP security Ike intermediate application policy.

Force Renewal

Administrators may wish to update all certificates immediately rather than wait until they renew to receive the new setting. The course of action depends on how certificates are issued.

On-Premises

When issuing certificates using Active Directory Certificate Services (AD CS) on-premises, right-click the Always On VPN device authentication certificate template and choose Reenroll All Certificate Holders. This will force all domain-joined clients with Autoenroll permissions on the template to renew their certificate on their next enrollment cycle, regardless of the certificate’s lifetime.

Intune

Follow the steps below to force re-enrollment for all certificate holders when deploying certificates using Intune.

SCEP Add the IP Security IKE Intermediate application policy to the Intune VPN policy. After this change is applied, Intune will reenroll all endpoints.

PKCS – A new Intune device configuration policy must be created that includes the IP security IKE intermediate application policy. Assign the new policy and remove the old one to replace all certificates.

PowerShell

It’s also possible to resolve this issue using PowerShell. Administrators can use the Set-VpnConnection PowerShell cmdlet to select a certificate based on the root certification authority (CA) or a specific custom application policy defined on the Always On VPN device authentication certificate. Be sure to add the -AllUserConnection switch when working with the device tunnel.

Root CA

Open a PowerShell command window and run the following command.

$RootCA = Get-Child-Item -Path Cert:\LocalMachine\My\<thumbprint of root CA certificate>
Set-VpnConnection -Name <name of VPN profile> -MachineCertificateIssuerFilter $RootCA

Application Policy

Open a PowerShell command window and run the following command.

Set-VpnConnection -Name <name of VPN profile> -MachineCertificateEKUFilter <OID>

Note: When using a custom application policy Windows will return a warning message stating the EKU could not be validated. You can safely disregard this warning.

Intune Remediation

While running PowerShell commands locally might be helpful for troubleshooting and targeted evaluation testing, deploying settings via PowerShell at scale is challenging. For those organizations managing their devices using Microsoft Intune, I’ve published a few detection and remediation scripts on GitHub to perform these tasks.

Summary

The intermittent Always On VPN 13801 IKE authentication credentials are unacceptable error message is best resolved by updating the Always On VPN device authentication certificate to include the IP security IKE intermediate application policy (EKU). Although using PowerShell also works, it doesn’t scale effectively. SCCM or Intune remediations can help, but I’d encourage you to update the certificate template as best practice instead.

Additional Information

Troubleshooting Always On VPN Error 13801

Troubleshooting Always On VPN Error 13806

Troubleshooting Always On VPN Error 13868