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

Strong Certificate Mapping Enforcement February 2025

Are you ready? In just a few short weeks(!) Microsoft will release the February 2025 security updates. This is a critical update because Microsoft plans to enable full enforcement of strong certificate mapping on Active Directory Domain Controllers (DCs) with this release. Administrators unprepared for this may incur outages for workloads using certificate-based authentication such as Always On VPN, Wi-Fi, and others.

Reminder: There’s still space available in my Certificates and Intune Masterclass. Register now!

KB5014754

Microsoft introduced strong certificate mapping with the May 2022 update KB5014754 to address vulnerabilities identified with certificate-based authentication. The update makes changes to Active Directory Certificate Services (AD CS) certification authorities (CAs) to embed the principal’s Security Identifier (SID) on issued certificates with a new certificate extension. The update also changes domain controller behavior to monitor and optionally enforce strong certificate mapping for authentication.

Enforcement Mode

When first introduced, the update is configured in compatibility mode. If a certificate that isn’t strongly mapped is presented for authentication, an event is recorded in the event log indicating that. Microsoft has been planning for years to enable full enforcement. After many delays, that time is now upon us. Specifically, full enforcement for strong certificate mapping will be enabled by default on DCs after applying the February 2025 security updates.

Note: Administrators can switch back to compatibility mode for now. See below for more details.

Limitations

Initially, the strong certificate mapping update was applied only to online certificate templates. Specifically, those templates are configured to build the subject name from Active Directory information. However, offline templates, where the subject name is supplied in the request, do not include this information by default. Crucially, any certificate issued with Microsoft Intune with PKCS or SCEP uses offline templates and is not strongly mapped. The lack of strong certificate mapping options for Intune-issued certificates forced Microsoft to delay its full enforcement deadline until these limitations were resolved.

Updates

In October 2024, Microsoft Intune announced support for strong certificate mapping for PKCS and SCEP certificates. Administrators can now configure these certificates to include strong certificate mapping. However, administrators must take action to affect this change.

PKCS

To enable strong certificate mapping for PKCS certificates, administrators must ensure that the certificate connector is running at least version 6.2406.0.1001. In addition, the following registry key must be configured on the connector server.

Key: HKLM\Software\Microsoft\MicrosoftIntune\PFXCertificateConnector
Name: EnableSidSecurityExtension
Type: DWORD
Value: 1

You can implement this change by opening an elevated PowerShell command window and running the following command.

Set-ItemProperty -Path ‘HKLM:\SOFTWARE\Microsoft\MicrosoftIntune\PFXCertificateConnector’ -Name EnableSidSecurityExtension -Value 1 -Force

The Intune Certificate Connector server must be restarted for this change to take effect. No changes are required on the PKCS certificate policy in Intune.

SCEP

To enable strong certificate mapping for SCEP certificates, administrators must add the following attribute/value pair to the Subject alternative name settings on their existing Intune SCEP certificate policy.

Attribute: URI
Value: {{OnPremisesSecurityIdentifier}}

Preparation

Administrators using certificate-based authentication against on-premises Active Directory should ensure all user and device authentication certificates include embedded SID information. For certificates issued on-premises, with Intune using PKCS or certificates issued by Entra Conditional Access, the certificate should now have the extension 1.3.6.1.4.1.311.25.2, including the principal’s SID.


SCEP certificates issued using Intune will include the following information in the Subject Alternative Name field.

URL=tag:microsoft.com,2022-09-24:sid:<sid>


Note: This applies to certificates issued using Cloud PKI for Microsoft Intune as those certificates are deployed using a SCEP device configuration policy.

Opt-Out

With the February 2025 security update, all domain controllers will be switched to full enforcement mode. Authentication requests using certificates without strong mapping will be denied in this configuration.

If your organization is not prepared to move to full enforcement mode, the February 2025 update allows administrators to opt out and switch back to compatibility mode by enabling the following registry key on all domain controllers.

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

You can implement this change by opening an elevated PowerShell command window and running the following command.

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

September 2025

Administrators are strongly encouraged to update all user and device authentication certificates before September 2025. With the September 2025 security update, Microsoft will no longer honor the opt-out registry settings and strictly enforce strong certificate mapping for all certificate-based authentication requests.

Troubleshooting

Certificate authentication is commonly used for Always On VPN and Wi-Fi authentication. If full enforcement mode is enabled on domain controllers and a certificate is presented for authentication that is not strongly mapped, administrators may see the following event log information recorded on the Network Policy Server (NPS).

Network Policy Server denied access to a user.

The details of the event include the following.

Reason Code: 16
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.

Obviously, the user does not enter their password when using certificates for authentication. However, the indication of a credential mismatch can be caused by missing strong certificate mapping information when the DC is in full enforcement mode.

Note: There are other causes for reason code 16 failures on NPS. Further investigation may be required to determine the root cause.

Additional Information

Training: Certificates and Intune Masterclass

Certificate-Based Authentication Changes and Always On VPN

Strong Certificate Mapping for Intune PKCS and SCEP Certificates

Entra Conditional Access Certificates with SID Information Now Available

Intune Strong Certificate Mapping Error

Strong Certificate Mapping Error with PKCS

KB5014754: Certificate-Based Authentication Changes on Windows Domain Controllers

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