Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Wireless clients not trusting well-known Certificate Authorities by default??

I'm using PEAP-MSCHAPv2 for wireless authentication.  The radius server is a Windows 2008 server running NPS.  The clients consist of a bunch of laptops (mostly running Windows).  Not all of these laptops are members of Active Directory.  So, pushing any type of policy out to all clients isn't feasible (ie. using a private PKI and using AD to push the server cert and wireless config to all domain members).  So we decided to use a public PKI and obtained a certificate for our radius server through a well known CA.  So far, so good.

When clients to go connect, they still get a nasty warning saying:

--START--

The credentials provided by the server could not be validated. We recommend that you terminate the connection and contact your administrator with the information provided in the details. You may still connect but doing so exposes you to security risk by a possible rogue server.
Details
Radius Server:           $radius
Root CA:                    $ca
The server "$radius" presented a valid certificate issued by "$ca", but "$ca" is not configured as a valid trust anchor for this profile. Further, the server "$radius" is not configured as a valid NPS server to connect to for this profile.
--STOP--
(I replaced the actual radius server name with $radius and the CA with $ca).
Doing a little digging, it appears this is just the expected behavior of the Windows wireless client???  What's the point of getting a signed cert by a well-known CA if the client is still going to get a nasty warning like this?
Web browsers certainly don't behave like this.  The only difference between a web browser and the wireless client is with a browser, you're always going after a URL (ie, you can match what the browser wants to connect to versus what the CN on the server's cert comes back with) whereas on the wireless client, you generally won't know the radius server you're going to authenticate against.  But, in either scenario, the server's cert is signed by a well known CA.
I found a nice post that mentions this, but no solution:
Well, I suppose a solution is to manually configure the client to trust certs issued by the CA and/or configure my radius server in the connection profile.  But that requires configuring each client.  And there's no way we can use AD to push a policy/cert to all clients.
So my questions are:
-is this really the expected behavior?
-so browsers generally trust the default CAs whose certs are stored on the OS by default but the wireless adapters don't?
1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: Wireless clients not trusting well-known Certificate Authori

Hi,

I'm not giving a complete answer but just bringing my 2 cents.

This problem is linked with the Windows wireless supplicant. Absolutely not your wireless adapter.

CSSC or Intel ProSet behave differently. (So if you have intel adapters, you might check that option).

But I admit I never tried certificate authentication with a public cert from a well known CA

Nicolas

===

Don't forget to rate answers that you find useful

9 REPLIES
Cisco Employee

Re: Wireless clients not trusting well-known Certificate Authori

Hi,

I'm not giving a complete answer but just bringing my 2 cents.

This problem is linked with the Windows wireless supplicant. Absolutely not your wireless adapter.

CSSC or Intel ProSet behave differently. (So if you have intel adapters, you might check that option).

But I admit I never tried certificate authentication with a public cert from a well known CA

Nicolas

===

Don't forget to rate answers that you find useful

New Member

Wireless clients not trusting well-known Certificate Authorities

I am having this same issue and confirmed that using the Intel ProSet software to manage the wireless adapter works without being prompted for a trust anchor.  The issue is most our guests are not going to be using the Intel tools to manage their adapter so we get to deal with the mess MS put us in.

New Member

So i came across this post

So i came across this post and even though it's old it doesn't seem to answered, the problem you experience is because the CA certificate "trusted" has been renewed on the domain, if your wireless connections uses the CA certficate to authenticate it's connection it needs to be updated, most domains would deploy this connection in a GPO, so you just need to tick the box in the connection settings to use the new certificate.

Hope this still helps some people

Bronze

Re: Wireless clients not trusting well-known Certificate Authori

Hi

Did you ever get this working with the windows wireless client? I am having exactly the same issue and haven't found much of a resolution yet.

Thanks,

Matt

New Member

Wireless clients not trusting well-known Certificate Authorities

I'm seeing the same too, the only difference is I'm using Cisco ISE with a public cert - but I'm getting the same error for clients authenticating. Accepting the cert allows the clients to authenticate.

Is there any work around or update to this that anyone knows of?

New Member

Wireless clients not trusting well-known Certificate Authorities

no one found a solution to this?

New Member

Wireless clients not trusting well-known Certificate Authorities

This is a limitation of the Windows wireless client.

http://support.microsoft.com/kb/2518158

Somewhere was an artical the described that Microsoft wirless client does not trust public root CAs by default.  Using a 3rd party utility like Intel Pro Set trusts all the 3rd party root CAs by default so you dont get this message.

Please respond to Microsoft and voice your problem maybe they will fix their wireless client to trust public root CAs.

Justin.

New Member

Wireless clients not trusting well-known Certificate Authorities

Hi all,

Has anyone had a chance to solve the issue?

Aleksei.

New Member

Wireless clients not trusting well-known Certificate Authorities

You could try packaging the certificate install into the Trusted Root into a small MSI and distributing it as an interim measure if Microsoft do intend to add it to their list of trusted CAs. If you want them to have access to this MSI prior to guest web-auth you may need to do a pre-auth acl that'll allow them to click a link to download the MSI.

33707
Views
0
Helpful
9
Replies
CreatePlease to create content