Security

Hi Everyone,

Customer is using PEAP MSCHAPv2 for corporate user WiFi connections. They have an array of devices (iOS, Windows, Mac) - and are aiming to make the user experience as seamless as possible.

They recently purchased a certificate from GoDaddy (Purpose = Server Auth, Client Auth), for the NPS server users are authenticating against.

iOS and Mac devices can no longer conect when the GoDaddy cert is selected in NPS (previously with an MS server cert, they could connect, with iOS devices prompting to Accept/Trust the server cert). Note that it appears that the GoDaddy Root CA is now part of iOS 5.0. 

Windows devices fail with NPS showing "unknown EAP type". PEAP is the EAP type selected under the NPS profile, although with the MS cert we had loaded previously, we'd simply disable server cert validation (on those PCs that didn't have the Root CA) and the connection worked OK. 

Hoping someone can provide guidance - anyone with experience using a public cert (VeriSign, GoDaddy, etc.) for PEAP? 

We found various articles on using public certs for PEAP, and followed guidance re what options to include in the cert - but it was pretty basic (i.e. Server Auth). 

---

@raphael wrote:

Hi Everyone,

Customer is using PEAP MSCHAPv2 for corporate user WiFi connections. They have an array of devices (iOS, Windows, Mac) - and are aiming to make the user experience as seamless as possible.

 

They recently purchased a certificate from GoDaddy (Purpose = Server Auth, Client Auth), for the NPS server users are authenticating against.

iOS and Mac devices can no longer conect when the GoDaddy cert is selected in NPS (previously with an MS server cert, they could connect, with iOS devices prompting to Accept/Trust the server cert). Note that it appears that the GoDaddy Root CA is now part of iOS 5.0. 

Windows devices fail with NPS showing "unknown EAP type". PEAP is the EAP type selected under the NPS profile, although with the MS cert we had loaded previously, we'd simply disable server cert validation (on those PCs that didn't have the Root CA) and the connection worked OK. 

 

Hoping someone can provide guidance - anyone with experience using a public cert (VeriSign, GoDaddy, etc.) for PEAP? 

We found various articles on using public certs for PEAP, and followed guidance re what options to include in the cert - but it was pretty basic (i.e. Server Auth). 

 

 

 

 

---

Did you check to  make sure that even though PEAP is selected in the NPS remote access policy, that you click on edit and make sure that the GoDaddy Cert is selected instead of nothing?  It is quite possible that the Godaddy Cert was not imported to the server properly or not selected in the NPS policy.

Hey Colin,

The certificate is definitely selected within the NPS policy.

There are two certificates on the server, one generated by the MS Root CA, and one from GoDaddy.

With the certificate issued by the MS Root CA selected, iOS, Mac, etc can connect OK (obviously with the Accept/Trust prompt upon connection. As soon as they select the GoDaddy cert, the iOS + Macs can no longer connect (tried on a number of devices to make sure nothing was being cached...).

FYI - The MS Root CA is not currently an option, as it's being decommissioned very shortly, plus they wanted the added benefit of a public root Ca so that other devices would not get prompted upon connection (although understand that not all devices come loaded with every root CA).

---

@raphael wrote:

Hey Colin,

The certificate is definitely selected within the NPS policy.

There are two certificates on the server, one generated by the MS Root CA, and one from GoDaddy.

With the certificate issued by the MS Root CA selected, iOS, Mac, etc can connect OK (obviously with the Accept/Trust prompt upon connection. As soon as they select the GoDaddy cert, the iOS + Macs can no longer connect (tried on a number of devices to make sure nothing was being cached...).

 

FYI - The MS Root CA is not currently an option, as it's being decommissioned very shortly, plus they wanted the added benefit of a public root Ca so that other devices would not get prompted upon connection (although understand that not all devices come loaded with every root CA).

 

 

If the Certificate does not work, you should contact GoDaddy to make sure that you are handling the certificate correctly and it is indeed for the purpose you intended.  At minimum, it should work with the IOS devices.  You should NOT have to change anything on the Aruba Controller.

The only organizations who benefit from a public CA are organizations who have a large number of devices that they do not control, like Universities.  If the majority of an organization's devices are part of their domain, their domain devices automatically trust the enterprise CA and group policy can be used to push the WLAN configuration without intervention from their helpdesk or the end user.  Even though you purchase a certificate from a public "trusted" CA, not all devices will trust it, and many of the devices that do trust it, like IOS, still require people to click on "Accept" the first time they see a certificate, which negates this benefit.  In addition, non-domain Windows users require helpdesk to touch all of their devices to make them connect, anyway, EVEN if they trust the certificate, just like the private CA.

Hi,

Verify if your certificate is compliant with the following Microsoft requirements:
Cryptography algorithm: RSA
Key lenght must not exceed: 2048 bits
Server Authentication purpose in EKU extensions: 1.3.6.1.5.5.7.3.1
Certificate CN Name must match the DNS name of the server

In addition I found bad documentation related to the integration of third party Certificates.
When adding Certificates from third party CAs, permissions of the MachineKeys folder must be changed to allow NPS to read the certificate's private key:

Change the permissions to the Machinekeys directory and the keys to allow the Administrators group and System account to have full control. To do this, perform the following steps:
In Windows Explorer, right-click on the \Documents and settings\All Users\Application Data\Microsoft\Crypto\RSA\Machinekeys directory.
OR
\Documents and settings\All Users.WINNT\Application Data\Microsoft\Crypto\RSA\Machinekeys directory
Note: These are hidden files. To view these folder and files, select the Show hidden files and folders radio button.
1. Click the Security tab.
2. Click the Add button.
3. In the Look In: dialog box, select the local machine.
4. Add the Administrators group with Full Control.
5. Click Advanced, and then click Add.
6. Select the Everyone group, and then click OK.
7. Make sure the following check boxes are selected:
List Folder / Read Data
Read Attributes
Read Extended Attributes
Create Files / Write Data
Create Folders / Append Data
Write Attributes
Write Extended Attributes
Read Permissions

Note: These are the default settings.
8. Click OK.
9. Select the Reset Permissions on all Child objects and enable propagation of inheritable permissions check box.


But be aware of the following when using PEAP authentication mechanism:

1- 802.1X - PEAPv0/MsCHAPv2
The PEAPv0/MsCHAPv2 authentication method is not a formal protocol that has been a consensus. Therefore, it is still in a draft form and it is subject to the following limitations:
- The Microsoft Client sends the username in the clear outside the TLS tunnel. This information allows an outside observer to record the names and valid to try dictionary attacks to find the password of the user.
- A wireless infrastructure using this authentication method is susceptible to attack by evil twins as described in the following link:
http ://www.suse.de/~lnussel/The_Evil_Twin_problem_with_WPA2-Enterprise_v1.1.pdf

2- Using a Public Certification Authority Certificate
Certificates from public CA are vulnerable to the chain of trust exploit as explained in the following link:
http: / / www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf
Wireless LAN profiles must be created in order to validate the RADIUS server's certificate authenticity to avoid being fooled. However, the wireless clients do not include intermediate CAs validation. Therefore, only deployment using private CAs can be immunized against this vulnerability.

Paul

I don't have anything particularly useful to add here, but just wanted to welcome Paul Gallant to the forum with an excellent first post. :)

I am also a fan of using private CAs for 802.1X.  In my experience, even if you use a public CA and even if the client machine has that CA in the trusted list, you still get prompted the first time you connect.  I haven't tested this exhaustively so it's just a general impression at this point.  Keep in mind that if you do use a public CA, it is critical that you configure specific RADIUS server hostnames in your 802.1X supplicant.  If you simply say "Trust GoDaddy certs" then anyone with a GoDaddy certificate can impersonate your network.  Using a private CA gives you a little bit more safety, since it's unlikely that a would-be attacker is going to obtain a server certificate from your private CA.

Thanks all for your input, and my welcome to you too Paul - very useful info you've provided! 

Regards,

  Raphael

I have an issue with IAS and Radius Server Cert für PEAP EAP-MS-Chapv2.

I have an running IAS Server.

Now i want a backup IAS Server.

I want to use the same verisign radius server cert from the working IAS.

So i exported / imported the cert into my backup radius server.

But on the backup radius, it has another DNS/hostname (as in Active Directory each computer must have its own unique dns name), so the CN of the verisign server certificate is different.

When client disables the option to check the servercertificate (on wlan settings .. security), the client can authenticate.

When the client has to check the servercertificate, the IAS eventlog says "unknown user or wrong password".

So it seems the client does not trust this second IAS server.

Does the CN in the Radius Servercert HAS TO be the same as the DNS/hostname of the IAS Radius Server?

Why? The client can not check via DNS as the client does obtain an IP AFTER successfull 802.1X auth, so HOW should the client be able to PROOVE if CN and DNS Name of the IAS Radius matches?

Thank you.

You can't do that.  You have to get a new certificate for the new server.

Are u sure?

I asked Verisign, and they say i can install that certificate on as many internal servers as i want.

WHO is checking if the CN Name of the Servercertificate does match the HOSTNAME / DNS Name of the RAdius-Server?

The client (supplicant) CAN NOT check that as it does not have network connection until it is authenticated via PEAP.

Maybe i can trick it with hosts file on the radius-server, as from logic point of view only the RADIUS Server can check if its Servercert CN does match with its own DNS/hostname...

Thank you

---

@spacyfreak wrote:

Are u sure?

 

I asked Verisign, and they say i can install that certificate on as many internal servers as i want.

 

WHO is checking if the CN Name of the Servercertificate does match the HOSTNAME / DNS Name of the RAdius-Server?

The client (supplicant) CAN NOT check that as it does not have network connection until it is authenticated via PEAP.

 

Maybe i can trick it with hosts file on the radius-server, as from logic point of view only the RADIUS Server can check if its Servercert CN does match with its own DNS/hostname...

 

Thank you

---

Maybe I misunderstood you.  The client checks the server certificate during authentication.  Did you just try just enabling only "Validate Server Certificate" without specifying the server on the client?

Hi

YES, on the supplicants /windowsXP clients its only marked to "validate servercertificate" on wlan settings - but there is NO radius-server Name entry on that tab. Also, on that tab all verisign root ca certificates are marked (as the radius servercert is from verisign).

I am very familiar with radius and peap, but simply cant get it WHY it does not work.

The only difference to my other radius-servers is this missmatch in CN and hostname of the radiusserver, as the verisign cert was copied by another radiusserver (where servercert CN and hostname match).

But i gave this verisign servercert also to other people inside my company for their internal radiusservers, and there it works, though the CN does not match the hostname/DNS name of the radiusserver.

confused lil bit..

 I would like to understand - WHO is checking if the CN and the host/dnsname of radius match.

The supplicant CANT check that, as it does not have network connection till authenticated - so how should it do a dns lookup without network connectivity, as it is not authenticated yet via PEAP? 

So who else could do a dns lookup - the wlan controller? Dont think so, it just passes EAP packets like some kind of auth-proxy, it does not check what is inside the EAP containers.

The Radius? Does it check if its CN matches its own DNS Name? Maybe - so then i could put the CN entry of the cert into the "hosts" file on the local radius server, to "cheat" so it can resolve its own name to the value in CN.

anyway - THANK YOU!

Like to hear some opinion from your expirience.

By the way - it WORKS now.

Even if the Radiusserver Cert CN does not match the Radiusserver DNS/Hostname.

I had to export the intermediate Verisign Certificate and import it again, then it worked...

**bleep**... : - )

---

@cjoseph wrote:

 

---

@raphael wrote:

Hey Colin,

The certificate is definitely selected within the NPS policy.

There are two certificates on the server, one generated by the MS Root CA, and one from GoDaddy.

With the certificate issued by the MS Root CA selected, iOS, Mac, etc can connect OK (obviously with the Accept/Trust prompt upon connection. As soon as they select the GoDaddy cert, the iOS + Macs can no longer connect (tried on a number of devices to make sure nothing was being cached...).

 

FYI - The MS Root CA is not currently an option, as it's being decommissioned very shortly, plus they wanted the added benefit of a public root Ca so that other devices would not get prompted upon connection (although understand that not all devices come loaded with every root CA).

 

 

---

If the Certificate does not work, you should contact GoDaddy to make sure that you are handling the certificate correctly and it is indeed for the purpose you intended.  At minimum, it should work with the IOS devices.  You should NOT have to change anything on the Aruba Controller.

 

The only organizations who benefit from a public CA are organizations who have a large number of devices that they do not control, like Universities.  If the majority of an organization's devices are part of their domain, their domain devices automatically trust the enterprise CA and group policy can be used to push the WLAN configuration without intervention from their helpdesk or the end user.  Even though you purchase a certificate from a public "trusted" CA, not all devices will trust it, and many of the devices that do trust it, like IOS, still require people to click on "Accept" the first time they see a certificate, which negates this benefit.  In addition, non-domain Windows users require helpdesk to touch all of their devices to make them connect, anyway, EVEN if they trust the certificate, just like the private CA.

 

 

 

---

Hi, sorry to bring this thread from the dead but its a high ranking search result on this topic and wanted to ask a question regarding this specific post.

You said that "in addition, non-domain Windows users require helpdesk to touch all of their devices to make them connect, anyway, EVEN if they trust the certificate, just like the private CA."

However, it must be possible to avoid this because time warner cable does it with their wifi-passpoint service.  It uses 802.1x EAP-PEAP MSchapv2 and while the user must accept their public cert in IOS, in Windows they dont have to accept anything and it just works (without messing with server certificate at all).  All a user of twcwifi-passpoint has to do is enter their username and password and it connects in windows 7 with no error and not even a warning or a prompt to accept the cert.

I have a large number of non-domain devices (android, IOS and windows) that i want to be able to use wpa2 enterprise on my network with only a eap-peap username and password.  I am ok with them having to accept the certificate on first connect but currently non-domain windows machines just error out and dont even ask about the certificate.  Upon adding the server certificate to the windows machine they still get an error (this is the error: http://i.imgur.com/i1jZI1Y.png).  

I want to do what timewarner cable has done with their passpoint service and get it so windows, android and ios can all connect with out messing with server certificates and custom settings, i just want them ot be able to enter a username and password.  It seems it must be possible since TWC is doing it with passpoint as can be seen here in their video: https://youtu.be/hHP9B-C_mYg?t=102

I know they are using a public certificate and I am ok with buying one but I had ruled out that idea based on the comment in this thread i referenced above about non-domain windows machines still needing custom setup by helpdesk.  After seeing what TWC is doing with passpoing i realized i should revisit this idea.

Thanks.

You will never be able to get rid of that dialog box unless you preconfigure clients or Onboard them. If you get a public certificate, all users should be able to connect after clicking the "Connect" button on that dialog.

For the TWC stuff, that's Passpoint 2.0 which has a different enrollment process.

---

@cappalli wrote:

You will never be able to get rid of that dialog box unless you preconfigure clients or Onboard them. If you get a public certificate, all users should be able to connect after clicking the "Connect" button on that dialog.

 

For the TWC stuff, that's Passpoint 2.0 which has a different enrollment process.

---

Ok, that is where my confusion comes in, I was told that passpoint uses eap-peap/mschapv2 w/ a public cert, I had no idea that passpoint was its own technology separate from eap-peap.  Can the passpoint 2.0 system be deployed by small organizations or is it only available to large entities?

What do you mean by onboard the clients? I am not familar with that term.

It uses underlying EAP technologies including EAP-PEAP and EAP-TLS but it is part of a larger framework. There would be no benefit to using hotspot 2.0 in a small environment. It would just add complexity.

Onboarding is the process of configuring the and/or installing a client certificate.

If you just get a public cert, most of your problems should disappear.

---

@cappalli wrote:

It uses underlying EAP technologies including EAP-PEAP and EAP-TLS but it is part of a larger framework. There would be no benefit to using hotspot 2.0 in a small environment. It would just add complexity.

 

Onboarding is the process of configuring the and/or installing a client certificate.

 

If you just get a public cert, most of your problems should disappear.

---

Ok thanks, its just very cool that they can seemlessy connect a windows machine for the first time with no prior preconfig by just entering a username and password.  you just double click on the SSID and enter your username and password and it connects, no cert warning or anything.  Hopefully this is something that will be available to the masses in a less complex form in the future.

I guess then my option is to buy a public signed cert, signed to my server fqdn and then have the users click connect and accept the cert error, although this is going to cause added complexity for the users.

With Hotspot 2.0 Release 2, the user goes through an onboard/enrollment process before getting access. This would be the equivalent of doing an Onboard certificate enrollment in an enterprise network. Many of the carriers that are saying they're using Hotspot 2.0 are actually just doing standard 802.1X. No secret sauce. Comcast, for example, has an XFINITY SSID which is just standard EAP-TTLS/PAP. Phase 2 for them will be HS2/R2.

Keep in mind that it's not an error. It's for your users protection. It's asking you whether you trust the server to authenticate you. Most organizations instruct the user to verify they see the companies domain before clicking accept.

@timcappalli

I'm facing the same problem with a customer, we have a public certificate installed at CP for radius, all CAs and intermeciated CAs are imported and valid at CP.

But we still getting the "accept" message when connecting to the 802.1x EAP/PEAP SSID.

There are any way to avoid that? other than implementing OnBoard?

No, this is completely normal. There are many presentations for Atmosphere on the topic. You either need to use a supplicant configuration utility or use Onboard (recommended).

recycling this old threat: 

I know on iphones you have to accept the certificate but can someone explain, why a public signed certificate is marked as "untrusted" on the iphones or how to get this certificate marked in green as trusted?

Please open a new thread.  Like you said, this one is many years old.

I'm going to hijack this thread a little, I've got a customer that uses a public signed (verisign) certificate on an IAS server to terminate the 802.1x PEAP tunnel on an SSID for non-domain devices. Problem is they still get certificate warnings.

I've checked the certificate and everything is correct according to Pauls previous mentioned demands except for the DNS name as CN of the certificate.

The certificate CN just says: "servername". Should it say: "servername.domain.local" for the authentication to go through without a warning?

Yes. The common name should be the FQDN of the server.

Clients can manually trust whatever CN is presented. Many users just click ok/accept to any message that pops up regarding the server cert.

Keep in mind that PEAP certificate trust is per connection profile. If the user does not have that SSID saved as a  network profile, they will most likely see the accept certificate (regardless of whether the computer trusts the root CA). It's not asking if you trust the certificate itself, it's asking if you trust the server that you are about to send your credentials to. The certificate is just the identity.