Reply
Aruba Employee
raphael
Posts: 5
Registered: ‎12-07-2011
Accepted Solution

PEAP - Public Certificates (GoDaddy / VeriSign)

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). 

 

 

 

 

Moderator
cjoseph
Posts: 12,129
Registered: ‎03-29-2007

Re: PEAP - Public Certificates (GoDaddy / VeriSign)


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.

 

Colin Joseph
Aruba Customer Engineering
Aruba Employee
raphael
Posts: 5
Registered: ‎12-07-2011

Re: PEAP - Public Certificates (GoDaddy / VeriSign)

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).

 

 

Moderator
cjoseph
Posts: 12,129
Registered: ‎03-29-2007

Re: PEAP - Public Certificates (GoDaddy / VeriSign)

[ Edited ]

 


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.

 

 

 

Colin Joseph
Aruba Customer Engineering
Contributor I
paul.gallant
Posts: 20
Registered: ‎01-23-2012

Re: PEAP - Public Certificates (GoDaddy / VeriSign)

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

Paul Gallant. Eng.
CWNA, CWSP
Moderator
jgreen
Posts: 187
Registered: ‎09-12-2007

Re: PEAP - Public Certificates (GoDaddy / VeriSign)

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.

---
Jon Green, ACMX, CISSP
Security Architect
Aruba Employee
raphael
Posts: 5
Registered: ‎12-07-2011

Re: PEAP - Public Certificates (GoDaddy / VeriSign)

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

 

Regards,

  Raphael

 

New Contributor
spacyfreak
Posts: 4
Registered: ‎06-30-2012

Re: PEAP - Public Certificates (GoDaddy / VeriSign)

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.

Moderator
cjoseph
Posts: 12,129
Registered: ‎03-29-2007

Re: PEAP - Public Certificates (GoDaddy / VeriSign)

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

 

Colin Joseph
Aruba Customer Engineering
New Contributor
spacyfreak
Posts: 4
Registered: ‎06-30-2012

Re: PEAP - Public Certificates (GoDaddy / VeriSign)

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