Security

I'm going to start out by saying that this is a bumpy road.

 

We use a WLAN cert from Verisign. Only some devices show it as verified. It all depends on the device's OS, as to whether or not a valid cert will show up as valid during 802.1x authentication.

 

Here's what I've seen so far:

Valid:

Android

OSX Lion

 

Unable to verify:

iOS

Windows

 

It is very odd. If you do some searches on it, you will find that most places (I'm in EDU, so lets just say Universities) tell the user to visually verify that the chain is correct.

 

So, the moral of the story is, don't waste your time banging your head against the wall if it shows up as "unable to verify" or "unverified" on the device. That being said, I would stick with someone like Verisign. The WLAN cert price is very reasonable.

 

Zach

@ mmeyer

 

Sorry for the re-ordering Mike. Moving under Authentication and Access Control forum for better visibility. 

 

 

---

@ozwifi wrote:

@ mmeyer

 

Sorry for the re-ordering Mike. Moving under Authentication and Access Control forum for better visibility. 

 

 

---

I was wondering why my response appeared before the original question. :robotwink:

 

Zach

I assume you guys are trying to setup PEAP or TTLS based 802.1x networks and the server certificate is giving you the grief. That is interesting that the iOS devices are showing a VeriSign certificate as not verified. I found this link on the Apple site showing the list of trusted CA's in iOS 5 and there are several entries for VeriSign:

 

http://support.apple.com/kb/HT5012

 

We have been working on several projects where we are leveraging the Apple Over-the-Air provisioning API to push the trusted server cert if it coming from a locally signed CA. Not sure if this style of solution would be of interest.

---

@-cam- wrote:

I assume you guys are trying to setup PEAP or TTLS based 802.1x networks and the server certificate is giving you the grief. That is interesting that the iOS devices are showing a VeriSign certificate as not verified. I found this link on the Apple site showing the list of trusted CA's in iOS 5 and there are several entries for VeriSign:

 

http://support.apple.com/kb/HT5012

 

We have been working on several projects where we are leveraging the Apple Over-the-Air provisioning API to push the trusted server cert if it coming from a locally signed CA. Not sure if this style of solution would be of interest.

---

Cam,

Yes, the root and intermediary are trusted by Apple devices. However, for some reason, I believe the iOS devices are trying to do an OCSP or CRL lookup on the cert. Since they are not connected to the network when they get the cert, they cannot verify that the intermediaries or roots are not revoked.

 

As far as being able to push a self-signed cert, that would save us about $600 a year. So, yes, that would be nice. I'm going to guess that would have something to do with Amigopod and the new acquisition (Avenda). But you would need to be able to check if the user failed to connect to the PEAP network do to a cert error and redirect them to the CP with the profile download. Otherwise people would just try to connect to the PEAP and complain when it fails because they don't have the cert.

 

Zach

Zach,

 

It would be interesting to see if the AuthorityInfoAccess or AIA attribute is set in the certificate you are experiencing issues with as this will potentially define an OCSP URL for revocation checking.

 

Yes, the ability to push a client certificate is part of the Amigopod Mobile Device Provisioning Service (MDPS). The idea is to leverage the contoller device fingerprinting to detect supported devices and then flip their role so the user is forced to enrol the device. The provisioning process can authorize the user against an exsiting user store such as AD and then push a device specific credential such as a TLS certificate. Having a device specific credential such as this will then allow you to revoke network access for that device (say it was lost or stolen) without impacting the user's access on other devices.

 

Cam.

Gents,

 

What is the best way to go about getting a signed certificate (not just a self-signed one from your local CA) onto your 2008 R2 server?  Right now my server is a domain member server running NPS, that is all.

 

I loaded up the Certificate snap-in from through MMC and do see the Request Certificate option when I look under Personal > All Tasks menu, is this the proper road to take or is there a better way to do it?

 

Thanks.

 

 

First, you need to install the Web Server IIS role.

 

Then you can create a cert request via the IIS Manager: Select the Server, double-click Server Certificates, right-click in the Server Certificates, choose "Create Certificate Request". This will walk you through the wizzard. Once the Cert coompany gives you your cert, you go into that window again, right-click, choose Complete Certificate Request.

So I've installed the IIS role, generated the CSR, had it signed, completed the Certificate Request.

 

Then I setup NPS and setup PEAP selecting that new cert from the drop down.  Then I tried connecting with a client on several different platforms (Apple, Android, BlackBerry, Windows), they pass network authentication but still show the cert as 'not verfied'.

 

Am I missing a step?  Does the domain name the cert is issued to matter?  For now I just used the FQDN of the server.

I've got the same issue as mmeyer.

 

We bought an external cert. Setup NPS to use it, and the devices still complain that it's not verified. I'm wondering if the device is attempting a CRL lookup and can't verify the cert status and that's what's causing the issue.

 

Our end goal is to have users connect without an annoying cert error warning. It seems like this is a common enough scenario that Aruba would have a document describing the procedure to get this in place.

The problem is that different devices trust different groups of CAs and even those devices, will alert you the first time they see a different certificate from a CA, even though they trust it.  The issue is between the devices and the Certificate Authorities, and the behavior they use to handle certificates. 

 

Bummer... It sounds like it's annoying by design... It's really no better than the self signed cert that I was using before.

 

Thanks cjoseph.

I have used the following nasty cli command to install another certificate that the NPS is required to trust in order to terminate EAP. I am not MS expert so I certainly hope there is another way to achieve the same result but it appeared to work for me:

 

certutil -enterprise -addstore NTAuth CA_CertFilename.cer

 

Hope this helps.

Thanks Zach.

 

How did you setup your WLAN cert from VeriSign?  Did you install it onto a CA server in your domain, or did you install directly onto the Aruba controller?

---

@mmeyer wrote:

Thanks Zach.

 

How did you setup your WLAN cert from VeriSign?  Did you install it onto a CA server in your domain, or did you install directly onto the Aruba controller?

---

I installed it directly onto our RADIUS server (Windows 2008 R2).

I'd like to +1 this thread, I have hit this limitation as well and my client is asking the question as to what benefit the public cert offers when you still can't verify the peap cert.

I am just running into this problem as well.

 

My thought process was that by terminating at the controller with a publically trusted cert of my choosing, we would be in a position to prevent the annoying warnings/validations from coming up.  In the EDU space, students bring a bevy of unmanaged clients on to the network, and I don't like advising "Just click ok if you get a cert error" or "disable the server validation" checkbox.

 

I originally thought I was having a chaining problem, but I tied the whole trust chain together into a single server crt file I used to terminate EAP on the controller.  Upon connecting, on a OSX Lion client if you click the "details" button it now shows a clean trust chain and just asks you to take a look at the certificate and subsequently adds it to the keystore.  On my iPhone4, I get a "Not Verified" warning.

 

My Android clients connect just fine. 

 

Anyone come up with a clean(er) solution to this problem? 

At the Airheads Conference in the Top 10 tips from TAC they talked about how to allow OCSP to verify certificates during authentication.  Could this be the solution to your problems?

 

http://community.arubanetworks.com/aruba/attachments/aruba/tkb@tkb/148/2/2012%20AH%20Vegas%20-%20Top10%20Tips%20from%20Aruba%20TAC.pdf

 

(Tip #7)

hi jaker,

 

Thanks for the info, i missed the airheads conference so it is good to see what was covered.

 

unfortunately that workaround is not able to help us in this case as the OCSP problems seem to be related to TLS / EAP authentication rather than SSL / Web authentication.

 

I believe there is an RFC in place that allows for client OCSP verification in the TLS exchange however this has not been implemented in any client devices yet.

 

Cam,

 

feel free to correct me if this is not the case.