Troubleshooting NDES Error 0x80094800 Unsupported Cert Type on Windows Server 2025

With Windows Server 2016 fast approaching end of life (EOL – January 2027) I’ve been helping many customers get their existing Network Device Enrollment Service (NDES) server upgraded to Windows Server 2025. In the past I’ve had few problems deploying NDES on Windows Server 2016, 2019, and 2022. However, NDES deployments on Windows Server 2025 have proven more challenging. Unlike previous releases, many installations fail during initial configuration with little indication of the underlying cause. The error described below is quite common, in my experience.

Unsupported Cert Type

When configuring the NDES role on Windows Server 2025, administrators may encounter an installation failure with the following error message.

Failed to enroll RA certificates. The requested certificate template is not supported by this CA. 0x80094800 (-2146875392 CERTSRV_E_UNSUPPORTED_CERT_TYPE)

Investigation

Inspection of the issuing CA confirmed that the required NDES certificate templates had been published successfully and were visible on the target issuing CA server.

After confirming the templates were published, I validated connectivity between the NDEs server and the issuing CA to rule out communication issues.

certutil.exe -config <servername\commonname> -ping

Root Cause

Although the precise root cause remains unclear, the issue appears related to timing or object availability during NDES configuration. In many cases it behaves like a delay in template publication visibility, Active Directory replication latency, or another dependency timing issue encountered during setup.

Note: This error can also occur if the administrator is not a member of the Enterprise Administrators group, or if the security permissions on these default templates has changed.

Recovery

Fortunately, if you encounter this issue you can usually just remove the configuration using PowerShell and run it again.

Uninstall-AdccsNetworkDeviceEnrollmentService -Force

However, in my experience running the installer again results in another error, usually the 0x80070003 ‘Path Not Found’ error. If that happens, see my published guidance for recovering from this error here.

https://directaccess.richardhicks.com/2026/05/26/troubleshooting-ndes-error-0x80070003-path-not-found-on-windows-server-2025

While recovery is usually straightforward, preventing the issue entirely is preferable.

Recommendation

I recommend publishing the required templates on the target issuing CA before proceeding with the NDES configuration. Publishing these templates manually before running NDES configuration ensures they are already visible and available to the CA, potentially avoiding timing-related enrollment failures during setup. The following default templates are required for NDES configuration.

  • IPsec (Offline request)
  • CEP Encryption
  • Exchange Enrollment Agent (Offline request)

Note: Best practice is to remove these templates after configuration because they are intended only for NDES registration authority enrollment and are not typically required for ongoing issuance.

Summary

When deploying NDES on Windows Server 2025, administrators may encounter the 0x80094800 CERTSRV_E_UNSUPPORTED_CERT_TYPE error even when the required templates appear correctly configured. Although the exact cause remains uncertain, the issue appears related to timing or template availability during setup. In most cases, removing and re-running the NDES configuration resolves the problem, while pre-publishing the default NDES templates before configuration can help prevent it entirely.

Additional Information

Troubleshooting NDES Error 0x80070003 Path Not Found on Windows Server 2025

Intune PKCS and SCEP Certificate Validity Period

TRAINING: Mastering Enterprise PKI Certificates with Microsoft Intune

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

The Case for 6-Day Public TLS Certificates

In February 2025, Let’s Encrypt introduced the option to enroll for public TLS certificates with a 6-day validity period.  This represents a significant shift toward short-lived certificates and aligns with the broader industry trend of reducing certificate lifetimes to improve security. While this may seem aggressive at first glance, organizations that have embraced automation will find that extremely short-lived certificates offer compelling security and operational advantages in some scenarios.

Benefits

Extremely short-lived TLS certificates offer several important security and operational benefits, particularly for organizations that have already embraced automation for certificate lifecycle management. Key advantages include:

  • Minimized Risk of Key Compromise – 6-day certificates dramatically reduce the exposure window of private key compromise events, giving attackers a limited window of opportunity to exploit key access.
  • Automation Validation – Short-lived certificates force organizations to adopt and validate automated enrollment and renewal processes, ensuring that certificate lifecycle management is reliable and resilient.
  • IP Address Support – 6-day TLS certificates from Let’s Encrypt support IP addresses, allowing administrators to secure workloads that do not have entries in DNS.

Use Cases

6-day TLS certificates are well-suited for a range of modern workloads, especially those that benefit from frequent key rotation, automation, and dynamic provisioning. 6-Day TLS certificates are well-suited for the following workloads:

  • High Value Resources – Using 6-day TLS certificates is beneficial for high-security or sensitive workloads where frequent key rotation is desired.
  • Test Labs – High-frequency certificate rotation allows for thorough testing of automation processes to ensure operational reliability of production deployments. Rapid iteration of 6-day TLS certificates allows administrators to identify potential issues and implement changes before long-term certificates expire.
  • Ephemeral Infrastructure – 6-day TLS certificates work well with dynamic workloads such as containers, where environments are rapidly provisioned and destroyed. These hosts might only live for a few hours or days, making short-lived certificates an ideal choice in this scenario.
  • Workload Bootstrapping – 6-day TLS certificates can be used where a certificate is required only to perform initial configuration. For example, an IP-based TLS certificate can be used to configure TLS services, then later migrated to a long-term certificate when DNS is configured and the service is placed into production.

Enterprise Usage

Administrators will find that 6-day public TLS certificates work well with many popular Windows Server workloads. Here are a few examples.

  • Always On VPN – Enterprise secure remote access is a popular target for attackers because the service is exposed to the Internet. Using 6-day TLS certificates ensures frequent key rotation, reducing exposure to key compromise.
  • Remote Desktop Services – Many organizations continue to use Remote Desktop Gateway to provide access to on-premises applications, another workload that is exposed to the Internet. Using 6-day TLS certificates is equally effective in this scenario.

What About DirectAccess?

Although DirectAccess would be another ideal Windows Server workload for 6-day TLS certificates, my testing shows that it does not work. The root cause is that 6-day TLS certificates from Let’s Encrypt do NOT include subject information (the field is blank). Unfortunately, because of the way in which DirectAccess validates this certificate, it requires information in this field. More details can be found here.

https://directaccess.richardhicks.com/2026/03/16/directaccess-iphttps-and-lets-encrypt-6-day-certificates/

Summary

If you are automating certificate enrollment and renewal, it shouldn’t matter if the certificate is valid for 6 days or 60 days. In fact, shorter lifetimes can significantly improve your security posture by minimizing risk and enforcing operational discipline around certificate management. Organizations that invest in automation today will be well-positioned to adopt even shorter certificate lifetimes in the future, while those relying on manual processes will find it increasingly difficult to keep up.

Questions?

Do you have questions about certificate lifecycle automation in your environment? I’m happy to help you validate your approach and address any challenges you’re encountering. Fill out the form below, and I’ll provide you with more information.

Additional Information

Let’s Encrypt Issues First Six-Day Certificate

DirectAccess IP-HTTPS and Let’s Encrypt 6-Day TLS Certificates

The Case for Short-Lived Certificates in the Enterprise