CertKit Agent Support for Always On VPN SSTP and DirectAccess IP-HTTPS TLS Certificates

With public TLS certificate lifetimes set to drop to 200 days soon (next week!), Always On VPN and DirectAccess administrators face an increased risk of service disruption if certificates aren’t renewed on time. These shorter certificate lifetimes require more frequent renewals, substantially increasing management overhead. Although 200 days equate to roughly a twice-a-year renewal, lifetimes will decrease further to 100 days next year and eventually to just 47 days in 2029. SSTP and IP-HTTPS are TLS-based tunneling protocols used by Always On VPN and DirectAccess, respectively, tying their certificate health directly to remote access availability. Now is the time to automate the enrollment and renewal of Always On VPN SSTP and DirectAccess IP-HTTPS/TLS certificates to ensure reliable operation in the future.

Always On VPN

Previously, I wrote about using CertKit.io to automate the enrollment and renewal of public TLS certificates for Always On VPN. CertKit is an online service that administrators can use to delegate the task of enrolling for short-lived certificates from Let’s Encrypt. In that post, I shared some sample code to retrieve the certificate from CertKit and assign it to the SSTP listener for the Routing and Remote Access Service (RRAS). However, CertKit added new features to its solution, eliminating the need for additional code.

CertKit Agents

Recently, CertKit introduced CertKit Agents. These lightweight software agents are installed on Windows Servers (other operating systems are supported as well) to automate the process of downloading CertKit certificates and installing them in the local computer certificate store. Importantly, they now specifically support both the Always On VPN (SSTP) and DirectAccess (IP-HTTPS) workloads natively.

Always On VPN

The CertKit agent automatically detects the Routing and Remote Access (RRAS) workload and updates the certificate binding for the SSTP listener accordingly. Since this process requires a service restart, which terminates all current VPN connections, CertKit allows you to select an outage window for certificate updates.

Here, administrators can define the day(s) and time window during which the agent is authorized to restart the RemoteAccess service when updating the TLS certificate for SSTP. The day and time are based on the server’s configured time zone settings.

DirectAccess

Beginning with CertKit agent v1.6.2, the agent automatically detects whether DirectAccess is configured, enabling IP-HTTPS TLS certificates to be automatically enrolled and renewed. However, additional configuration is required. The following changes must be made to support CertKit for DirectAccess.

  • Service Account – Administrators must configure a service account in Active Directory for the CertKit agent. A Group Managed Service Account (gMSA) is preferred, but a standard domain service account is also supported.
  • GPO Delegation – CertKit service account must be delegated the ‘Edit settings, delete, and modify security’ permission on the DirectAccess server and client settings GPOs.
  • Log On as a Service – When using a domain service account, administrators must grant the CertKit service the ‘Log on as a service’ right on the DirectAccess server. However, when using gMSA, the ‘Log on as a service’ right is not required.
  • Local Administrator – Administrators must also add the CertKit agent service account to the Local Administrators group on the server.

Configuration Script

I have published a PowerShell script to simplify configuring the CertKit agent on DirectAccess servers. The script automatically performs all required tasks for the CertKit agent to work with DirectAccess. You will find the Enable-DACertKit.ps1 PowerShell script on GitHub. Alternatively, you can install the script directly from the PowerShell Gallery.

Install-Script -Name Enable-DACertKit -Scope CurrentUser

After installing the CertKit agent, run the PowerShell script to complete the configuration. Next, authorize the agent in the CertKit management portal and assign a certificate. Once complete, CertKit can fully manage the IP-HTTPS TLS certificate for DirectAccess.

Note: Like Always On VPN, changes to the DirectAccess IP-HTTPS certificate require a service restart, which is disruptive. Be sure to define a maintenance window (as shown previously) to ensure the change is made during non-peak times.

Summary

As TLS certificate lifecycles continue to shrink, automating certificate enrollment and renewal has become essential for both Always On VPN and DirectAccess environments. CertKit agents streamline this process by automatically retrieving, installing, and binding certificates for SSTP and IP-HTTPS, all while supporting scheduled outage windows to minimize disruption. With these new capabilities, administrators can significantly reduce operational overhead and ensure consistent, reliable remote access services without manual intervention. Visit CertKit.io to get started today.

More Information

If you would like to learn more about CertKit or see a demonstration with Always On VPN or DirectAccess, fill out the form below, and I’ll provide you with more details.

Additional Information

Always On VPN SSTP Certificate Automation with CertKit

CertKit Agents

Enable-DACertKit.ps1 on GitHub

Enable Group Managed Service Accounts

Always On VPN SSTP Certificate Automation with CertKit

With public TLS certificates moving to significantly shorter certificate lifetimes, eventually just 47 days, Always On VPN administrators supporting Secure Socket Tunneling Protocol (SSTP) connections must prepare to address this eventuality. The first milestone for shortened public TLS certificate lifetimes is a few months, on March 15, 2026, when public TLS certificate lifetimes will be reduced from a maximum of 398 days to 200 days. One year later, on March 15, 2027, they will be reduced to just 100 days. Now is the time to begin planning an automated certificate enrollment solution to reduce administrative overhead and ensure uninterrupted connectivity for remote users.

Previous Approaches: PowerShell and Posh-ACME

In the past, I’ve written about using Let’s Encrypt Certificates for Always On VPN using the Posh-ACME PowerShell module. I’ve also posted some sample code to demonstrate how to integrate with a DNS provider to automate publishing the ACME challenge to public DNS for certificate enrollment verification. However, this assumes your DNS provider supports this option. Some do not. In addition, granting write permissions to public DNS via an API key introduces significant security risks. So, if direct ACME DNS automation isn’t viable in your environment, CertKit is an excellent alternative.

CertKit: Automated Certificate Issuance, Monitoring, and Alerting

To address these limitations, administrators can use the CertKit service. With CertKit, you delegate the Let’s Encrypt certificate enrollment process to them by simply creating a CNAME record in your public DNS. Once complete, CertKit handles the entire process transparently.

Issuance

Today, CertKit supports issuing certificates using Let’s Encrypt. In the future, support for additional certificate providers such as Google Trust and ZeroSSL will be added. CertKit supports Let’s Encrypt certificates using RSA (2048-bit) and Elliptic Curve (recommended). Certificates can be issued for an individual resource, a group of resources (multi-SAN), and a domain wildcard (e.g., *.example.net).

Monitoring

In addition to certificate issuance and management, CertKit offers domain TLS certificate monitoring to track your public assets. You can monitor your CertKit-managed certificates easily, but you can also add other services using TLS and track them on the same console. In this example, I’m using CertKit to manage certificates for two VPN servers (indicated by solid green dots) and to monitor my public websites, for which certificate management is handled by their respective hosting providers.

Alerts and Notifications

CertKit will automatically send emails to let you know when a certificate is expiring and if a CertKit-managed certificate has been renewed.

Pending certificate expiration.

Successful certificate renewal.

Certificate Retrieval

Once CertKit completes the enrollment process on your behalf, it stores all certificate files (.PFX, .PEM, and .KEY) in a secure S3-compatible storage bucket. While an administrator could easily retrieve and install them manually, automation will help reduce administrative overhead, especially as public TLS certificate lifetimes are further reduced. You can download certificate files programmatically in several ways.

PowerShell

The first way to download the certificate files from CertKit is to use the AWSPowerShell module. However, the AWSPowerShell is relatively heavy and is overkill for this specific use case. A better alternative is to use the MinIO client.

MinIO

The MinIO client (mc.exe) is an open-source command-line tool developed by MinIO. It provides access to any S3-compatible storage, which CertKit uses in its environment. MinIO is a single, portable executable installer that’s easy to use and well-documented.

Sample Code

I’ve published some sample code to demonstrate how to use the MinIO client to retrieve certificates from CertKit and install them on a Windows Server Routing and Remote Access (RRAS) server. You can find the sample code on GitHub here.

https://github.com/richardhicks/aovpn/blob/master/Install-SstpLetsEncryptCertificate-Certkit.ps1

Note: This sample code demonstrates how to download a .PFX file from CertKit and install it on the RRAS server. It is designed to run as a scheduled task in Windows during non-peak times. The code includes robust checks for service viability and will reboot the server if they fail. As such, this sample code could cause service disruptions, so use it with caution.

Cost

Today, CertKit is in beta and is free for everyone to use. In the future, there will be both free and paid tiers. You can learn more about their pricing models and sign up for the service at CertKit.io.

Learn More

If you’d like to learn more about CertKit and how you can leverage it for Always On VPN and other workloads in your environment, or you’d like to see a demonstration of CertKit, fill out the form below, and I’ll provide you with more information.

Additional Information

CertKit

Install-SstpLetsEncryptCertificate-Certkit.ps1 on GitHub

Always On VPN SSTP and 47-Day TLS Certificates

Always On VPN SSTP with Let’s Encrypt Certificates

Resolving PKCS Certificate Mapping Issues in Windows Autopilot Hybrid Join Deployments

Microsoft Windows Autopilot streamlines device provisioning through Intune, allowing IT administrators to preconfigure new Windows devices with minimal hands-on effort. However, when combined with Hybrid Entra Join and PKCS certificate deployment, specific challenges arise—particularly with certificate mapping and authentication.

Hybrid Entra Join

During autopilot provisioning, administrators may also choose to join the device to their on-premises Active Directory domain, a deployment model called Hybrid Entra join. Hybrid Entra join presents some unique challenges when using Autopilot to remotely provision devices. Specifically, the user must have connectivity to a domain controller to perform the first logon, as they do not have a user profile on the endpoint.

Device Tunnel

To support offline Hybrid Entra join during Autopilot provisioning, administrators can deploy the Always On VPN device tunnel to provide pre-logon connectivity to domain controllers. A device tunnel connection enables users to log on to their newly provisioned device remotely.

Requirements

The following prerequisites must be met to support the Always On VPN device tunnel.

  • The endpoint must be running Windows Enterprise edition.
  • An Always On VPN device tunnel profile must be assigned to the device.
  • A machine certificate must be deployed to the endpoint that includes the Client Authentication EKU (OID 1.3.6.1.5.5.7.3.2).

Note: If you plan to use the subscription step-up upgrade from Windows Professional to Windows Enterprise, the device tunnel will not connect automatically after provisioning is complete, which prevents the user from logging in. More details and a workaround for this issue can be found here.

Strong Certificate Mapping

Microsoft knowledge base article KB5014754, released in May of 2022, introduced changes to domain controllers to require strong certificate mapping when using certificates to authenticate to Active Directory (AD). It was initially deployed in compatibility mode, only warning administrators when certificates are used for authentication that aren’t strongly mapped. However, full enforcement is mandatory beginning with the September 2025 security updates. This requirement introduces some challenges when issuing certificates to the device using PKCS during Autopilot provisioning.

Intune PKCS Certificates

When using PKCS certificates and the Intune Certificate Connector, the endpoint’s on-premises AD security identifier (SID) is not added to the issued certificate during Autopilot. Interestingly, this does not happen when using SCEP certificates. If the device certificate is not strongly mapped, the Always On VPN device tunnel will still authenticate successfully because Always On VPN does not use AD to authenticate device connections. Instead, Always On VPN simply verifies the certificate (e.g., that it is not expired or revoked) and allows authentication if the certificate passes the validation.

However, enterprise Wi-Fi access may fail without strongly mapped certificates if device authentication is required. Also, there may be other scenarios where a device authentication certificate without strong mapping may cause authentication to fail.

Workarounds

There are a few ways to work around this limitation. Consider the following options.

Native Entra ID Join

The simplest way to avoid the challenges of PKCS certificates and Hybrid Entra join is to avoid it altogether in favor of native Entra join. However, this may not be an option for everyone.

Use SCEP

For some reason, certificates issued with SCEP do not suffer from this limitation. In my testing, SCEP certificates are always strongly mapped. However, deploying SCEP certificates is much more complex than using PKCS. (Pro tip: Cloud PKI for Intune uses SCEP and requires no configuration! It’s definitely something to consider.)

Short-Lived Certificates

Another option is to deploy temporary, short-lived certificates (valid for only a few days) using PKCS to ensure the Always On VPN device tunnel works, and then deploy a permanent, long-term certificate post-deployment that includes the strong mapping. To do this, administrators can leverage dynamic group assignments in Intune. For example, the administrator can assign the short-lived certificate to an Autopilot Provisioning devices group and later assign a long-term certificate to the Hybrid Joined devices group.

Here’s an example of the dynamic group membership configuration.

Autopilot Provisioning Devices:

(device.devicePhysicalIDs -any (_ -contains “[ZTDId]”)) -and (device.deviceTrustType -ne “ServerAD”)

Hybrid Entra Join Devices:

(device.deviceTrustType -eq “ServerAD”)

In this configuration, the initial PKCS certificate is deployed without the strong mapping when the endpoint is enrolled to Autopilot but has not yet joined the domain. During this time, the endpoint will only be a member of the Autopilot Provisioning Devices group and will receive the short-lived, temporary certificate. Later, once the endpoint has successfully joined the domain, the device will move from the provisioning group to the Hybrid Entra Join Devices group. When this happens, a permanent, strongly mapped long-term certificate is enrolled on the device.

Manual Certificate Mapping

Certificates can be manually mapped via the altSecurityIdentities property of the computer object in AD. Obviously, this doesn’t scale well, so my good friend Steve Prentice published a PowerShell script to automate this process. You can find more details and the script here.

Summary

Windows Autopilot streamlines device provisioning with Intune, but Hybrid Entra Join introduces challenges when PKCS certificates lack strong mapping during initial deployment, potentially disrupting VPN and Wi-Fi authentication. Administrators can avoid this by switching to native Entra join or by using workarounds such as switching to SCEP, using short-lived certificates, or manually mapping certificates.

Additional Information

KB5014754 – Certificate-based authentication changes on Windows domain controllers

How To: Map a user to a certificate via all methods available in the altSecurityIdentities attribute

Hybrid Autopilot: Automating altSecurityIdentities

Configure Microsoft Entra hybrid join

Overview: Cloud PKI for Microsoft Intune