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

What’s New in Always On VPN DPC 4.3.1

The latest release of PowerON Platforms’ Always On VPN Dynamic Profile Configurator (DPC), version 4.3.1, is now available for download. This recent update includes fixes for previously known issues. In addition, it contains some critical new features administrators will find helpful in addressing the challenges they face with Always On VPN client configuration.

What Is DPC?

Always On VPN DPC is a solution to manage Always On VPN client configuration settings. It was originally designed to be used with on-premises Active Directory but can also be deployed with Microsoft Intune. DPC streamlines the configuration and management of client settings and includes many advanced features to fine-tune and optimize Always On VPN.

What’s New in 4.3.1

The following essential features are new in the 4.3.1 release of DPC.

Add Device Tunnel Routes to User Tunnel

Always On VPN administrators can now configure DPC to add device tunnel routes to the user tunnel automatically. This configuration option ensures that all traffic flows of the user tunnel when both user and device tunnels are established.

Note: This feature also requires administrators to define route metric options in DPC. Ensure the user tunnel route metrics are set to a lower value than the device tunnel metrics for proper operation.

Restart RasMan

Always On VPN connections occasionally fail with error 602 (ERROR_PORT_ALREADY_OPEN). The workaround for this is to restart the RasMan service on the endpoint. DPC now supports automatically restarting the RasMan service when this error occurs, ensuring reliable operation for Always On VPN connections.

Machine Certificate Filtering

DPC 4.3.1 now includes a feature to allow administrators to enable machine certificate filtering for Always On VPN device tunnels. This addresses a challenge when the endpoint has multiple machine certificates in its local computer certificate store when the VPN server is configured to accept a certificate with a specific custom application policy (EKU).

Additional Features

In addition, the updated DPC agent core service now run as x64 processes. Also, DPC now supports VPN server FQDNs longer than 63 characters (good news for those using DPC with Azure VPN gateway!).

Download DPC

For those customers currently licensed for Always On VPN DPC you can download the latest release here.

https://support.poweronplatforms.com/support/solutions/articles/8000066807

Not using DPC?

If you’re not using DPC, you are missing out! You can learn more about DPC and register for a free evaluation by visiting the link below.

https://aovpndpc.com

Optionally, you can fill out the form below and I’ll provide you with more information.

Additional Information

PowerON Platforms’ Always On VPN Dynamic Profile Configurator (DPC)

Always On VPN DPC Advanced Features

Always On VPN DPC with Microsoft Intune

Always On VPN Client IP Address Assignment Methods

When Always On VPN clients connect to the VPN server, they must be assigned an IP address to facilitate network communication. When using Windows Server and Routing and Remote Access Service (RRAS) for VPN services, administrators must choose between Dynamic Host Configuration Protocol (DHCP) and static address pool assignment methods.

DHCP

DHCP is a quick and easy way to handle VPN client IP address assignment. However, there are some drawbacks and limitations associated with this option. Consider the following.

Allocation

DHCP for Always On VPN clients does not work as you might expect. For example, when a VPN client connects, it does not obtain its IP address directly from the DHCP server. Instead, the VPN server leases a block of IP addresses from the DHCP server and manages those on behalf of its clients. On the DHCP server, you will see the Unique ID column of these IP address leases indicating RAS.

Address Block Size

After configuring the VPN server to use DHCP VPN client IP address assignment, the VPN server will automatically lease a block of ten IP addresses from a DHCP server. When this initial block of ten IP addresses is exhausted, the VPN server will lease another block of ten IP addresses. Administrators can increase the size of the requested address block by creating the following registry key on each VPN server.

Key: HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\IP
Value: InitialAddressPoolSize
Type: DWORD
Data: <size of DHCP pool request>

Alternatively, administrators can download Update-VpnServerDhcpPoolSize.ps1 from my GitHub repository and run it on each VPN server to increase the size of the initial DHCP address pool request.

DHCP Options

The VPN server discards all DHCP option information returned by the DHCP server. The VPN server uses only the IP address from the DHCP lease. The client is unaware of any other information in the DHCP lease.

Subnet

By default, the VPN server will only request DHCP addresses from a scope that matches the same subnet as the IP address assigned to the VPN server’s network adapter. If the VPN server has more than one network interface, it will send DHCP requests from the network interface listed on the Adapter drop-down list, as shown here.

Note: This option is only available on servers configured with multiple network interfaces. Also, if the value is set to Allow RAS to select adapter, it is best to specifically define the network interface where DHCP and DNS requests are made.

Scope Size

When using the DHCP assignment method, ensure the DHCP scope contains enough IP addresses to support the number of concurrent connections expected on all VPN servers.

IPv6

DHCPv6 is not supported on RRAS for VPN client IP address assignment. The only option for IPv6 is prefix assignment.

RRAS in Azure

DHCP is not supported when deploying RRAS in Azure. Administrators deploying RRAS in Azure to support Always On VPN must use the static address pool assignment method. More details here.

Known Issues

When using DHCP with Windows Server 2019 RRAS servers, a known issue prevents this from working correctly. Administrators can download Update-VpnServerDhcpPrivileges.ps1 from my GitHub repository and run it on each VPN server to ensure proper DHCP operation.

Increased Complexity

Since the VPN server leases IP addresses on behalf of clients and discards DHCP option information included in the lease, there’s no real benefit to using DHCP. Using DHCP only adds complexity and introduces another dependency, making the solution more brittle and difficult to manage. Using the static address pool assignment method is a better choice.

Static Pool

Implementation best practices dictate using the static address pool assignment method instead of DHCP. The following is guidance for configuring RRAS to support the static address pool option for VPN client IP address assignment.

Unique Subnet

Using a unique IP subnet is best when using the static address pool assignment method. However, this also requires configuring internal network routing to return traffic for that subnet to the individual VPN server where that subnet is assigned. Each server must have a unique IP address pool assigned. Define static address pools using subnet boundaries when configuring multiple VPN servers. Assigning IP address pools along subnet boundaries simplifies internal network routing configuration. Ensure that assigned IP address pool subnets are large enough to accommodate the total number of concurrent connections expected on each server. Be sure to overprovision to handle failover scenarios.

Same Subnet

Alternatively, administrators can assign VPN client IP addresses from the same subnet as the VPN server’s network interface. Assigning VPN client IP addresses from the same subnet as the VPN server eliminates the need for any internal network routing configuration, simplifying deployment. However, server subnets are often small and may not have enough IP address space to support numerous concurrent VPN connections. Be sure to plan accordingly.

Static IP Addresses

It is possible to assign a static IP address to an individual user. However, assigning a static IP address to a specific device is not. I will discuss static IP address assignments for Always On VPN clients in a future blog post.

Other Limitations

Here are some additional things to consider when creating a VPN client IP addressing strategy.

DNS

Always On VPN clients can be configured to register their IP address in DNS. However, the VPN client configuration controls this setting. The DHCP server does not register IP addresses in DNS when using DHCP. The client registers its IP address in DNS directly after it connects. In addition, a VPN client will receive a different IP address each time it connects to the VPN server. DNS propagation can delay hostname resolution on-premises for remote-connected VPN clients.

Selective Addressing

Regardless of which assignment method is selected, assigning different IP addresses to different types of connections is not possible. For example, a common ask is to assign user connections from one IP address pool and device connections from another. The only option to support this is to use different servers for each type of connection.

Summary

The best practice for IPv4 VPN client addressing is to use the static address pool method with a unique IPv4 subnet per server. Using static address pool assignment provides the most flexible configuration options and eliminates the dependency on internal services, making the solution more resilient and easier to manage. A unique address pool per server ensures that a large enough subnet can be defined to support the expected number of concurrent connections, regardless of the subnet size the VPN server is assigned to. Also, a unique IP subnet for VPN clients makes configuring internal firewall rules to control VPN client access easier.

Additional Information

Always On VPN and IPv6

Always On VPN Client DNS Server Configuration

Always On VPN Routing Configuration

Always On VPN RRAS Internal Interface Non-Operational