All posts tagged PowerShell

Always On VPN RRAS and PowerShell 7

PowerShell is an essential tool for administrators supporting Microsoft Always On VPN. It is critical for configuring supporting infrastructure services, such as Routing and Remote Access (RRAS) and Network Policy Server (NPS), as well as provisioning and managing Always On VPN client configuration settings on endpoints. The current version of PowerShell, PowerShell 7.5.3, is a game-changer for scripting and automation, bringing a host of improvements over its predecessors. PowerShell 7 offers better performance, lower memory usage, and cross-platform support (Windows, macOS, and Linux), making it more versatile than ever.

Problem in PowerShell 7

Recently, I discovered an oddity with PowerShell 7 when reviewing the configuration of an RRAS server. Specifically, PowerShell 7 differs in the way it produces output for the Get-RemoteAccess command, preventing administrators from viewing the details of the currently configured TLS certificate used for SSTP VPN connections in RRAS.

PowerShell 5

Running Get-RemoteAccess in PowerShell 5 provides detailed information about the SslCertificate property in the output of the command, as shown here.

Note that the data returned in the SslCertificate property is of the type X509Certificate2.

PowerShell 7

In PowerShell 7, Get-RemoteAccess displays only a string of numbers instead of detailed certificate information.

Notably, the data returned in the SslCertificate property is of the type System.Byte.

Solution

While PowerShell 7 doesn’t output the certificate details in human-readable form, you can easily convert the data using the following PowerShell command.

[System.Security.Cryptography.X509Certificates.X509Certificate2]::new((Get-RemoteAccess).SslCertificate) | Format-List

AovpnTools Module

To simplify administration, I’ve added a function to my AovpnTools PowerShell module called Get-VpnServerTlsCertificate. This function allows you to view the currently configured SSTP certificate details directly with a single command. In addition, you have the option to save the certificate to a file for further inspection and troubleshooting.

The GetVpnServerTlsCertificate function is included in AovpnTools v1.9.8 and later. You can install AovpnTools from the PowerShell gallery by running the following command.

Install-Module -Name AovpnTools

You can also find the AovpnTools PowerShell module on GitHub.

Summary

With PowerShell 7, RRAS certificate details display differently, but administrators can quickly resolve this using a simple conversion or the Get-VpnServerTlsCertificate function in the AovpnTools module. Either way, administrators can continue to use PowerShell 7 to manage their Windows Server RRAS servers.

Additional Information

Installing PowerShell 7 on Windows

AovpnTools in the PowerShell Gallery

AovpnTools on GitHub

Configure Windows Server DNS64 for IPv6-Mostly and IPv6-Only

Many organizations are modernizing their networks by migrating from legacy IPv4 to IPv6. The goal is to replace IPv4 with IPv6 entirely. However, even though an organization can successfully migrate to IPv6-only networks internally, they do not control networks outside its boundaries. In some cases, a host on an IPv6-only network may need to communicate with an IPv4 resource. Administrators must deploy an IPv6 transition technology to support this scenario. A common solution to address this need is DNS64 and NAT64.

What are DNS64 and NAT64?

DNS64 and NAT64, defined in RFCs 6147 and 6146, respectively, work together to ensure endpoints on an IPv6-only network can still communicate with IPv4-only resources. DNS64 enables IPv6-only clients to communicate with IPv4-only servers by synthesizing AAAA DNS records from A records. When an IPv6-only client queries a domain with only an IPv4 address (A record), the DNS64 server creates a synthetic IPv6 address by embedding the IPv4 address within an administrator-defined NAT64 IPv6 prefix. The default (referred to as ‘well known’) prefix is 64:ff9b::/96. In the example below, the IPv4-only resource ipv4.test-ipv6.com is resolved using the Cloudflare public DNS64 resolver.

Using the synthetic DNS64 address allows the client to send IPv6 packets to a NAT64 gateway, which translates them to IPv4 for the destination server. DNS64 ensures seamless address resolution for IPv6-only networks accessing IPv4 resources without requiring actual IPv6 addresses for the target.

Caveat

While DNS64 is great for ensuring IPv4 access on IPv6-only networks, it has one critical limitation. The client must connect to a resource using a hostname or a fully qualified domain name. If a client attempts to connect to an IPv4 resource directly (e.g., https://172.16.21.12 or \\10.21.12.83\data), the resource will be unreachable. To address this limitation, the 464XLAT IPv6 transition technology must be used. For more information about 464XLAT, see my previous article, Microsoft Begins Rolling Out Windows CLAT for IPv6-Mostly and IPv6-Only Networks.

Enterprise DNS64

While there are public DNS64 resolves from Cloudflare, Google, and others, they aren’t helpful when trying to resolve internal hostnames in the enterprise. Organizations must deploy their own private DNS64 services in this scenario.

Windows Server and DNS64

Today, Windows Server does not natively support DNS64. Organizations are advised to use an enterprise DNS solution such as Infoblox or BlueCat for DNS64 services. Alternatively, administrators can deploy BIND DNS on the Linux platform of their choice. DNS64 is supported in BIND 9.8.0 and later.

DNS64 Proxy

To support testing and evaluation (and perhaps production deployment for smaller organizations), it is possible to configure any supported version of Windows Server to serve as a DNS64 proxy. In this scenario, a Windows Server is configured as a DNS64 server, but the server itself is not an actual DNS server. It does not have a DNS database or zone file; it is not authoritative for any zones and can’t perform conditional forwarding. It simply forwards DNS queries to the servers defined on its own network interface.

Windows Server DNS64 Configuration

The DNS64 service must be installed using PowerShell and the Set-NetDnsTransitionConfiguration command. Administrators will define some variables, configure DNS64, and create firewall rules to allow DNS traffic inbound to the server.

Configure DNS64

On a Windows Server member server (domain-join is optional), open an elevated PowerShell command window and run the following commands.

# Define variables
$AcceptInterface = ‘Ethernet’ # The interface name or alias that will accept DNS64 traffic
$SendInterface = ‘Ethernet’ # The interface name or alias that will send DNS64 traffic
$Nat64Prefix = ’64:ff9b::/96′ # The NAT64 prefix

# Configure DNS64
Set-NetDnsTransitionConfiguration -State Enabled -AcceptInterface $AcceptInterface -SendInterface $SendInterface -PrefixMapping “$Nat64Prefix,0.0.0.0/0” -PassThru

Configure Windows Firewall

Run the following PowerShell commands to configure the Windows Firewall to allow inbound DNS requests.

# Create firewall rules to allow DNS64 traffic inbound
New-NetFirewallRule -Name ‘DNSSrv-DNS-UDP-In’ -DisplayName ‘DNS (UDP, Incoming)’ -Description ‘Inbound rule to allow remote UDP access to the DNS64 service.’ -Group ‘DNS64 Service’ -Protocol UDP -LocalPort 53 -Direction Inbound -Profile Any -Action Allow -Enabled True

New-NetFirewallRule -Name ‘DNSSrv-DNS-TCP-In’ -DisplayName ‘DNS (TCP, Incoming)’ -Description ‘Inbound rule to allow remote TCP access to the DNS64 service.’ -Group ‘DNS64 Service’ -Protocol TCP -LocalPort 53 -Direction Inbound -Profile Any -Action Allow -Enabled True

GitHub

For reference, I’ve posted the relevant commands for configuring DNS64 on Windows Server on GitHub here.

DNS64 Testing

Once DNS64 is configured on the Windows Server, administrators can test operation by sending a DNS query for an IPv4-only resource to the DNS64 server using the following PowerShell command.

Resolve-DnsName -Name ipv4.test-ipv6.com -Server <DNS64 server IPv6 address>

For example.

Resolve-DnsName -Name ipv4.test-ipv6.com -Server 2001:579:6024:510::64

The DNS64 server responds with the native IPv4 address along with the synthesized IPv6 address. However, if the target resource has only an IPv6 address or has both IPv4 and IPv6 addresses, both are returned, as shown below.

Summary

DNS64 and NAT64 are essential tools for enabling communication between IPv6-only networks and IPv4 resources. While public resolvers exist, enterprises often need their own DNS64 service for internal hostname resolution. Windows Server does not natively support DNS64, but administrators can configure it as a DNS64 proxy for testing and smaller deployments. In this scenario, Windows Server can provide DNS64 functionality, helping organizations transition toward IPv6-only networks while maintaining access to legacy IPv4 systems.

Additional Information

Microsoft Begins Rolling Out Windows CLAT for IPv6-Mostly and IPv6-Only Networks

Configure DHCP Option 108 on Windows DHCP Server

IPv6 Transition Technology Options – IPv6 Buzz Podcast

Set-NetDnsTransitionConfiguration

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

1 Comment

by Richard M. Hicks on April 22, 2025 • Permalink

Posted by Richard M. Hicks on April 22, 2025

https://directaccess.richardhicks.com/2025/04/22/always-on-vpn-sstp-and-47-day-tls-certificates/

Richard M. Hicks Consulting, Inc.

Microsoft MVP

Consulting

Pluralsight

Newsletter

All posts tagged PowerShell

Always On VPN RRAS and PowerShell 7

Problem in PowerShell 7

PowerShell 5

PowerShell 7

Solution

AovpnTools Module

Summary

Additional Information

Share this:

Like this:

Configure Windows Server DNS64 for IPv6-Mostly and IPv6-Only

What are DNS64 and NAT64?

Caveat

Enterprise DNS64

Windows Server and DNS64

DNS64 Proxy

Windows Server DNS64 Configuration

Configure DNS64

Configure Windows Firewall

GitHub

DNS64 Testing

Summary

Additional Information

Share this:

Like this:

Always On VPN SSTP and 47-Day TLS Certificates

47 Days

Automation

Why Is This Happening?

Advantages

Why 47 Days?

Not So Fast

Let’s Encrypt

Sample Script

Act Now

Summary

Additional Information

Share this:

Like this:

Always On VPN Book

DirectAccess Book

Masterclass

Yubikey

Recent Posts

Resources

Always On VPN Resources

DirectAccess Resources