Microsoft AD CS Adds Post-Quantum Cryptography Support with ML-DSA

Despite predictions of its decline, Microsoft Active Directory Certificate Services (AD CS) continues to evolve. Following significant enhancements introduced in late 2025, including CRL partitioning and support for 16K database pages, the May 2026 update adds another important capability: support for Post-Quantum Cryptography (PQC).

ML-DSA

Specifically, the May 2026 update adds support for ML-DSA-44, ML-DSA-65, and ML-DSA-87 in Windows Server 2025 for AD CS. This enables administrators to begin evaluating post-quantum cryptographic algorithms and assessing PQC readiness in enterprise PKI environments

Configuration

After applying the May 2026 update to an issuing Certification Authority (CA), administrators will find new PQC algorithms under the Algorithm name drop-down list, as shown here.

Note: If you don’t see these new algorithms, ensure you have selected Key Storage Provider from the Provider Category drop-down list. In addition, ensure that you select Signature on the Request Handling tab.

Test Results

Initial testing across common enterprise certificate scenarios produced mixed results. While PQC works well in some scenarios, other workloads still show limitations.

Code Signing

Code signing with an ML-DSA-44 certificate issued by AD CS works perfectly. For example, I can use Set-AuthenticodeSignature to sign a PowerShell script, as shown here.

Viewing the file’s properties shows that the encryption algorithm used to sign the file was ML-DSA-44, as expected.

IIS

TLS-based workloads proved more challenging. Attempts to configure an HTTPS binding in IIS failed with the following error message.

There was an error while performing this operation. A specified logon session does not exist. It may already have been terminated. (Exception from HRESULT: 0x80070520).

RRAS and SSTP

Similar limitations occurred when testing remote-access VPN scenarios using RRAS and SSTP. Specifically, configuring a PQC TLS certificate for SSTP in RRAS failed. Although I was able to assign the certificate using Set-RemoteAccess, the RemoteAccess service failed to start.

Remote Desktop

Unfortunately, using PQC certificates for RDP also fails. Although I could assign the PQC certificate to the RDP listener, clients fail to connect using RDP and return the following error message.

This computer can’t connect to the remote computer. Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator.

Error code: 0x904
Extended error code: 0x7

Summary

The May 2026 update marks an important milestone for AD CS by introducing initial support for PQC algorithms, allowing organizations to begin evaluating ML-DSA certificates in enterprise environments. Early testing shows promising results for signing scenarios such as code signing; however, broader infrastructure workloads, including TLS, VPN, and Remote Desktop, remain limited today. Although PQC support is still in its early stages, these updates demonstrate Microsoft’s ongoing investment in AD CS and provide administrators with an opportunity to begin preparing their PKI environments for the post-quantum future. Additional PQC enhancements, including ML-KEM support and broader ecosystem integration, are anticipated in future Windows updates.

Additional Information

Microsoft May 2026 Security Updates (KB5087539)

Post Quantum Cryptography in the Enterprise

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

Always On VPN SSTP and HSTS

HTTP Strict Transport Security (HSTS) is a feature commonly used by websites to protect against protocol downgrade attacks, where an attacker forces the use of insecure HTTP instead of HTTPS. If successful, the attacker can intercept unencrypted communication between the client and the web server. This is undesirable for obvious reasons. As such, web server administrators implement an HTTP response header named Strict-Transport-Security with some additional settings that instruct the user agent, in this case, a web browser, to only use secure HTTPS when communicating with the web server. Attempts to use HTTP will not work.

VPN and SSTP

As security is always a top concern when building an Always On VPN infrastructure, careful attention must be paid to VPN protocol configuration to ensure optimal security. Secure Socket Tunneling Protocol (SSTP) is a popular VPN protocol for Always On VPN user tunnel connections. SSTP uses Transport Layer Security (TLS) for encryption, so administrators are encouraged to implement recommended security configurations, such as disabling insecure protocols like TLS 1.0 and TLS 1.1 and optimizing TLS cipher suites as described here.

SSTP with HSTS

It would seem that enabling HSTS on a Windows RRAS VPN server would be ideal for improving SSTP security. However, that’s not the case. HSTS prevents protocol downgrade attacks from HTTPS to HTTP, but SSTP already uses HTTPS exclusively, making the use of HSTS irrelevant. If an attacker attempted a protocol downgrade attack on an SSTP VPN connection, it would fail because the service does not support HTTP between the client and the VPN gateway. Additionally, even if it were possible to configure RRAS to send an HSTS response header, it would be ignored by the client because the user agent is not a web browser.

Additional Information

Always On VPN SSTP Security Configuration

Always On VPN SSTP and TLS 1.3

Always On VPN SSTP Certificate Renewal

Always On VPN SSTP with Let’s Encrypt Certificates

Always On VPN SSTP Certificate Binding Error

SSL and TLS Training for Always On VPN Administrators