Ok I am trying to get NPS setup that will be used for guests to access the Internet but still require a login on our network using PEAP. I got a trial certificate from GeoTrust/RapidSSL/FreeSSL and it only offers "Digital Signature, Key Encipherment (a0)" but NPS requires a certificate with "Data Encipherment". I have not found ANY public CA that issue this type of certificate so if Microsoft requires this for PEAP where am I to get a valid certificate for this?
I have check Verisign, and GoDaddy and all of them only offer "Key Encipherment".
- Düzenleyen yaplej 10 Aralık 2011 Cumartesi 01:39
Well I have wasted an entire day on this. I have gone round and round the technet site looking up requirements for the certificate used for nps. It only makes mention that it must specifically include "Server Authentication" Extended Key Usage. This however does not seam to be adaquate for nps to work with PEAP.
According to the artical above you must "make sure that the Purpose option is set to Signature and Encryption" now to me "Encryption" would equal the Key Usage option of "Data Encipherment". However, none of the public CAs I contacted offer certificates with that Key Usage. I have generated multile self-signed certificates and all of them include "Data Encipherment" and seem to work well for NPS but this is unacceptable in my case where we want guest systems to natively trust logging onto our network.
Does anyone know of a CA that offers certificates with "Data Encipherment" as an enabled Key Usage?
This topic is good for you to read: http://technet.microsoft.com/en-us/library/cc772401(WS.10).aspx
The server certificate on NPS must have the server authentication EKU and the client must have the correct trusted root certification authority certificate. You can achieve this with a Microsoft certification authority server or a 3rd party certificate. You must have this certificate on NPS or it won't let you configure a policy that uses the PEAP authentication method. I am not sure where you found the Data Encipherment EKU requirement, but the one you need for PEAP is server authentication.
Reguardless of what that document says PEAP does not work with any certificate that does not have the Key Usage of Data Encipherment. All public CA certificates I have found (GoDaddy, VeriSign, GeoTrust) do not have that listed in the Key Usage field. They only have Signature and Key Encipherment their Extended Key Usage is always set to Server Authentication and Client Authentication but that does not work for NPS becasue they are missing the "Data Encipherment" Key Usage option.
If you generate a self-signed certificate I noticed it included the Key Usage option of "Data Encipherment" so that does work provided you trust the key on the NAP clients or disable "Verify Server" on the client. If the certifciate does not have the Key Usage Data Encipherment option the NPS server logs "EAP Type not not supported cannot be processed by this server" paraphrased.
I can assure you all the public CA certificates I have tried include the Extended Key Usage (EKU) option of Server Authentication but that alone does not work with NPS. You can get a free trial certificate from FreeSSL (GeoTrust) that is trusted on 99% of systems and NPS will not work with it because public CAs dont issue certificates that include "Data Encipherment" as a Key Usage.
The certificate NPS/NAP uses must be used to encrypt data directly using the certificate rather than generate a private key to be used for each session. Its probably fast/easier to code that way but its much more secure to require each session negotiate a private key pair for each session. Because most of these CAs are issueing certificates for HTTPS it makes sense they disable "Data Encryption" to ensure each web session is generating a unique key and not encrypting data with the certificate directly.
I am not an expert on PEAP but according to wikipedia PEAP uses the servers public key to encrypt data. With the certificates from public CAs exclude that particular use.
"PEAP is similar in design to EAP-TTLS, requiring only a server-side PKI certificate to create a secure TLS tunnel to protect user authentication, and uses server-side public key certificates to authenticate the server. It then creates an encrypted TLS tunnel between the client and the authentication server. In most configurations, the keys for this encryption are transported using the server's public key."
- Düzenleyen yaplej 13 Aralık 2011 Salı 06:53
We are referring to two different things here. A certificate has Key Usage and Extended Key Usage (EKU).
Another requirement is for the subject alternative name. Have you checked this on your public cert?
We followed your direction and purchased a certificate with SANs for all four of our NPS servers. As per the KB articles this certificate has EKU of "Server Authentication" and SANs for each of the NPS FQDNs. We installed the certificate and tested but we still suffering from the same issue. EAP Type is not supported with this certificate.
So we are going back again that PEAP requires Data Encipherment not just Key Encipherment Key Usage. The SAN might prevent the certificate from being trusted but we are not even getting that far.
Where do we go from here?
I've always used my own CA to issue certificates. Is there a reason why you can't install certification authority in your environment? I think we can solve the problem using 3rd party certificates, but if you are able to install a CA this might be simpler.
Please let me know,
We will be having vendors and systems that will not trust our internal CA. I tested this with an internal CA and was able to verify it works without the Key Usage option Data Encipherment but the certificate issued by the public CA still does not work. We are going to try some certificates from other public CAs to see if any of them work.
On NPS, do you see the certificate in the enterprise NTAuth store?
Issue this command to view:
certutil -v -store -enterprise ntauth
P.S. I found a GUI method: Certutil –viewstore –enterprise NTauth
This will show you the trusted Root certificate. It is the same certificate that you should see in the (correction added here) Enterprise Trust container in the local computer certificate MMC.
Make sure also that the certificate is being imported correctly. At a command line, type MMC, click File... Add/Remove Snap-in, click Certificates, click Add, choose Computer account, click Next, choose Local computer, click Finish and click OK. View the certificates in Certificates (Local Computer)\Personal\Certificates.
- Düzenleyen Greg LindsayMicrosoft employee, Owner 16 Aralık 2011 Cuma 01:28
The command "certutil -v -store -enterprise ntauth" seems to be the same as "Enterprise Trust" container in the local computer certificate MMC and it is empty. "Trusted Root Certification Authoriteis" contian has all the public CA root certificates listed.
So we tried to generate the CSR with IIS7 on a laptop and get a new certificate but that didnt work.
Then we tried to generate a certificate with IIS7 directly on the NPS it... also didnt work.
Have you added the 3rd party certificate to the enterprise NTAuth store on NPS?
I have had to do this before in a different scenario, but it might help here. If this doesn't help I'll have to either do some testing myself and/or find someone with 3rd party certificate experience.
certutil -enterprise -addstore NTAuth cert.cer
- Düzenleyen Greg LindsayMicrosoft employee, Owner 16 Aralık 2011 Cuma 02:07
What should I be adding to the enterprise NTAuth store?
I already tried adding the root CA public certificate and it didnt make any difference. I dont think that would be any help for PEAP because if I export the certificate from my test NPS server I have that used a Microsoft PKI it works. That PKI is in a totally separate domain and was not trusted but it still worked for PEAP on these new NPS servers I am setting up. I also could not find any differences between the certificate from our test PKI and the public CA in terms of EKU and Key Usage options.
So I know my NPS configuration is good because it works great with a self-signed certificate or a certificate from a MS PKI/Enterprise Root CA. Minus having to "trust" the certificate on some clients and disable Server Validation on Windows clients.
For whatever reason when I select the public CA certificate for PEAP it cannot process PEAP requests.
So here are some of the details from our public certificate issued by a common public CA."General" tab of certificate.
This certificate is inteded for he following purpose(s): Ensures the identity of a remote computer Proves your identity to a remote computer 2.16.840.1.1144188.8.131.52.1 Issued to: nps.domain.blah Issued by: Public CA Secure CA Valid from 12/ 15 / 2011 to 12/ 15/ 2016
"Details" tab of certificate.
Version "V3"The certificate looks perfectly fine to me. Unles you see something that would prevent it from working.
Serial number "Hex Stuff"
Signature algorithm "sha1RSA"
Signature hash algorithm "sha1"
Issuer "####, Public CA Secure CA"
Valid from "date"
Valid to "date"
OU=Domain Control Validated
Public key "RSA (2048 Bits)"
Enhanced Key Usage "
Server Authentication (184.108.40.206.220.127.116.11.1)
Client Authentication (18.104.22.168.22.214.171.124.2)"
Subject Alternative Name"
DNS Name=nps.domain.blah DNS Name=www.nps.domain.blah
Basic Constraints "
Entity Path Length Constraint=None"
Key Usage "Digital Signature, Key Encipherment (a0)"
- Düzenleyen yaplej 19 Aralık 2011 Pazartesi 18:57
Yes, the certificate shows up and allows me to select it. The error message shows in the NPS logs when a client tries to connect. If I change the certificate for a self-signed certificate or a certificate issues by a MS Enterprise root CA it works. Even if the certificate is not trusted. This is the event generated when a client tries to connect and NPS is trying to use the public certificate.
Network Policy Server denied access to a user. Contact the Network Policy Server administrator for more information. User: Security ID: NULL SID Account Name: myguest Account Domain: DOMAIN Fully Qualified Account Name: DOMAIN\myguest Client Machine: Security ID: NULL SID Account Name: - Fully Qualified Account Name: - OS-Version: - Called Station Identifier: 001d.7095.3dfa Calling Station Identifier: f81e.df3b.7e3a NAS: NAS IPv4 Address: <private ip> NAS IPv6 Address: - NAS Identifier: W-AP1 NAS Port-Type: Wireless - IEEE 802.11 NAS Port: 844 RADIUS Client: Client Friendly Name: W-AP1 Client IP Address: <private ip> Authentication Details: Connection Request Policy Name: NAP 802.1X Network Policy Name: - Authentication Provider: Windows Authentication Server: DC01.domain.blah Authentication Type: EAP EAP Type: - Account Session Identifier: - Logging Results: Accounting information was written to the local log file. Reason Code: 22 Reason: The client could not be authenticated because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server.
It must have something to do with the SAN requirement. I have been meaning to follow up on this by reviewing the EAP logs but holidays have kept me pretty busy. I am going to be out for the next week also on vacation, but it sounds like you might have found a solution anyway. I'm sorry I wasn't able to provide more helpful advice on this thread.
Thank you for your question.
I am trying to involve someone familiar with this topic to further look at this issue.
Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact firstname.lastname@example.org.
TechNet Community Support
Use OID "126.96.36.199.4.1.3188.8.131.52" to get a certificate that has Data Encipherment as a Key Usage.
This might be useful:
How to enable LDAP over SSL with a third-party certification authority http://support.microsoft.com/kb/321051
Sumesh P - Microsoft Online Community Support
Turned out that the Data Encipherment Key Usage mades no difference. The working public certificate does not have Data Encipherment so that was not the problem. The problem is related to the multi-domain public certificate. I dont know why it is not working while the single domain certificate is. They are both from the same public CA.
If we can review the EAP logs to figure out why the multi-domain certificate didnt work that would be great. I did not want to get a certificate for each of our NPS servers if I could use the multi-domain certificate.
Hope everyone had a great Holiday and Christmas.
- Düzenleyen yaplej 27 Aralık 2011 Salı 18:03
I am glad to see that you have realized the problem with your certificate. As Greg noted, the KU was correct. One of the additional requirements is the SAN field which must contain the FQDN of the server as noted in KB814394:
"the Subject Alternative Name (SubjectAltName) extension contains the server's fully qualified domain name (FQDN)."
While you have the FQDN, it does not look like it is the first entry. When RAS-TLS is looking for a valid certificate, it is looking in the SAN at the first entry which does not match the name of the server, so RAS-TLS will skip this certificate, hence the error that you were getting.
A single certificate issued to all your servers, unfortunately, will not work.
Clay Seymour - MSFT
While that may be the case that NPS only looks at the first entry in the SAN field it does not fully explain the issue. I have for instance used certificates that do not match the FQDN at all and the NPS was still able to authenticate using PEAP. Using this multi-domain certificate however it does not and will not even process the PEAP requests.
I have used certificates from another domain that in no way matches the FQDN or even the DN and RAS-TLS did not skip that certificate and was able to accept and process PEAP requests. Why then if it was willing to user a certificate issued to another domain name would it skip the certificate just becase the FQDN did not match. It also didnt match the other and was still willing to use it.
Does NPS RAS-TLS behave different when the domain name does not match?
No, I could never get it to work with a multi-host SAN certificate. Even though MS stated the issue was because the first entry in the SAN did not match the RAS-TLS service would not use the certificate I found in many other cases where the RAS-TLS service would use a certificate where the first entry in the SAN field did not match the FQDN at all yet still worked although with a certificate warning being presented to the user.
I'm having the same issue and want to verify what kind of certificate I should purchase. So for a single NPS I would want to request a single name cert with the server name (ie nps01.local) as the subject name? Is it fine to just create the CSR from IIS?