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.
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 https://www.sourceallies.com 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.
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 sourceallies.com.
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.
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
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" ).
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.
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.
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.
