Server 2022 - NPS - Radius (PEAP) - LE Certificate Issue


Certificate generated with posh-ACME ( Powershell script )
Certificate shows as valid, and ISRG Root X1 is in the Trusted Root Certification Authorities.
Confirmed the Certificate's chain is valid and is using X1 instead of X3.

NPS running on Windows Server 2022.
NPS Policies using PEAP assigned the LE certificate initially connect, but do not provide the certificate to the device for acceptance. WiFi connection continuously spins and eventually faults out.

What I have done to prove the certificate is ok:
Windows Server 2012R2 - NPS - Policy for AP using PEAP assigned the LE certificate. Connecting to the AP correctly provided the Certificate for acceptance as trusted. Accepting certificate connected to the WiFi connection.

What I have done to verify AP has connectivity to NPS:
Windows Server 2022 - NPS - Created a self signed certificate, assigned Certificate to NPS Policy for AP using PEAP. Connecting to the AP correctly provided the self signed certificate for acceptance as trusted. Accepting certificate connected to the WiFi connection.

This issue looks to be Windows Server 2022 using LE certificates for NPS Policies.

Any information would be greatly appreciated.

1 Like

Welcome @sblommers

First, I am not good with Windows servers and do not know what NPS or PEAP are.

But, could you state the problem with the domain or certs in simpler terms? I ask because the DNS for that domain points to Amazon CloudFront and uses Amazon certs.

And, requests to returns a valid html page that CloudFront got from an AmazonS3 origin server. Requests to the http URL are directed to https by CloudFront.

So, that domain and its certs look perfectly fine to me.

I apologize in advance if I have completely missed the point.

curl -I

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 21204
Connection: keep-alive
x-amz-id-2: 7TUbsbEdl8xxVH2DY4aPloW5vG1XjkEicgMUOW2kddQrxBrBoP5XFtVT8Zd4kxmM+0AphvHHGW4=
x-amz-request-id: AGJJDV63VJRGPWN6
Last-Modified: Wed, 08 Dec 2021 19:27:35 GMT
Accept-Ranges: bytes
Server: AmazonS3
Date: Fri, 21 Jan 2022 22:01:30 GMT
ETag: "802d080c04de0abc561d00885cd16ba7"
X-Cache: RefreshHit from cloudfront
Via: 1.1 (CloudFront)
X-Amz-Cf-Pop: IAD66-C1
X-Amz-Cf-Id: 5UWGRu2zCl_y3kWU6UqQyMACo6Udu-LNfsRKTg6KZVYSXqXRRvqr4g==

NPS is Microsoft's implementation of RADIUS (Remote Authentication Dial In User Service). RADIUS is used to authenticate users that are attempting to connect to a WiFi instance.

PEAP is Protected Extensible Authentication Protocol. This first has the user accept a certificate, then provide their user credentials. The credentials are passed as plain text, but are encrypted by the selected certificate. In this instance an LE certificate for the domain

We are using the posh-ACME client to generate the certificate. The client uses an AWS user account to validate domain ownership for certificate generation.

The issue we are having is that on a Windows 2022 server, when selecting the LE cert for the NPS policy, the certificate is not being presented to the user for acceptance even though the certificate is valid.

If we create a self signed certificate, everything works correctly.

1 Like

Thanks for the coherent explanation. Sadly, I am not able to assist.

I did not see any other threads with NPS or PEAP in this forum. Just want you to know there may not be sufficient expertise among the volunteers to provide much advice. Hopefully someone will be more useful than I have been :slight_smile:


This sounds like a question for @rmbolger : Using Let's Encrypt for Active Directory Domain Controller Certificates - Adventures in Tech

In general you need to ensure all the necessary services have been update/restarted and verify the different services individually.

Windows event viewer (perhaps with optional logs enabled) will likely tell you things that have failed.

Things I would suspect include:

  • are all the correct hostnames on the certificate
  • is the ISRG Root X1 (root) certificate trusted by all servers and clients involved
  • is the private key RSA and is it a compatible key size
  • is the private key accessible to the service (i.e. was the certificate stored to the machine certificate store or to a user certificate store and is it in the correct store .e.g should it be in "My" ).

See also: Certificate requirements when you use EAP-TLS - Windows Server | Microsoft Docs


Location, Location, Location!

In the "working" example, where is the self-signed cert placed?
Can you copy/move the LE cert there?

1 Like

Unfortunately I've never touched PEAP. But that doc @webprofusion linked to, particularly the "Server certificate requirements" section should be checked with a fine-toothed comb to make sure the requested LE cert adheres to every bullet point. MS services can be notoriously picky about seemingly dumb stuff like that.

Notably, needing the root cert to be in the Enterprise NTAuth store seems like a weird but easy to miss requirement. Also, note the differences between requirements about the Subject vs SubjectAltName.


The Certificate is in the Computer's Personal account.
MMC -> [Console Root\Certificates (Local Computer)\Personal\Certificates

This is the location the certificate needs to be for the NPS Policy to be able to see it for selection.

Thanks for the response. I may have left out some fairly important information.

We are not using a Domain Controller or trying to LDAPS into AD. We are using Azure's Active Directory with Domain Services so there is no need for a Domain Controller to be installed on the Server.

From what I've experienced, the Domain Name used to generate the certificate doesn't affect being able to use the certificate for the NPS Policy.

I noticed that the ISRG Root X1 certificate was missing from the "Third-Party Root Certificate Authorities" on the server, so I've added it there. I will post back here if that resolves the issue.


Adding the ISRG Root X1 cert to "Third-Party Root Certificate Authorities" did not fix the issue. I will continue digging. Thanks for the help guys!


Note also that ISRG Root X1 needs to be in the client machines "Trusted Root Certification Authorities" in order for certificates with that root to be trusted by the client machines. It probably is there, otherwise many public sites wouldn't work, but it's common for Windows machines to be out of date because root certificate updates are often disabled (usually because the admin disabled them years ago in group policy and forgot to re-enable them).


Thanks for the information. When adding a certificate to the "Third-Party Root Trusted Certification Authorities", the certificate is automatically added to the "Trusted Root Certificate Authorities" group.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.