Question about Certificates

[runningboy01]

We have a customer that has a need to get rid of the Securit Warning users see each time they log onto the Guest Wireless and go to use the internet. I believe the best way to do this is to install a 3rd party certificate. I found this link:

http://www.cisco.com/en/US/partner/tech/tk722/tk809/technologies_configuration_example09186a00806e367a.shtml

I assume if I follow that this should work for them. Is that correct? Is there any other way or better way to do this?

The customer is running 4.2.176 WLC Software and can not go to any version of 5 due to older APs.

Thanks in advance

[Robert.N.Barrett_2]

It worked for me with one MAJOR caveat. That document doesn't mention what do with a chained certificate. I think that all the newly-issued 3rd Party certs are chained.

In my limited PKI understanding, a chained cert comes from an intermediate CA, not the root. Therefore, in order to use a chained cert, the controller has to have three certs loaded: the root, the intermediate, and the device cert. I can't find the URL, but google "chained cert openssl" and I think you can figure out how to create the chain. If I remember correctly, you download the root and intermediate from the 3rd party cert provider, and just tack the device cert and private key onto the end of the file (assuming all files are in the same format, which I think needs to be PEM format). We used Entrust, and that's what I had to do. The only thing I can't recall for sure is the order of entries in the file: root->intermediate->device, or device->intermediate->root.

Be glad your customer is already on 4.2.176.0. 4.2.130.0 does not support chained certs.

Oh - one other "gotcha": make sure the clients also trust the intermediate CA. If they don't trust the root and the intermediate CA, then users will still get the security warning in their browser.

[runningboy01]

Per Cisco Support:

"There are two ways to eliminate the WLC cert prompt when clients are connecting to a web auth WLAN:

1. Download a trusted 3rd-party cert into the WLC as described by the link you referred to (Document ID: 70584). The documentation is pretty thorough and will provide step-by-step instructions. WLC 4.2.176.0 only supported unchained certs; WLC 5.1.151.0 or later releases support chained certs.

2. Alternatively, HTTPS can be disabled and clients will then be redirected from the WLC via HTTP only and no certificates will be used.

However, HTTPS will also be disabled for WLC management and security will be compromised."

Looks like 4.2.176 doesn't even support chained certificates.

[Scott Fella]

I use RapidSSL for most of my deployments when it comes to getting rid of the certificate error. The issue a root CA cert so it is not chained. I would also suggest you get at least a 3 year cert so you don't have to worry about it for a while. It is also a a trusted CA:

Equifax Secure Global eBusiness CA-1

Here is a simple text file I put together for some of my peers.

[Robert.N.Barrett_2]

According to the original bug report, the chained cert issue was "Fix in" in 4.2.159.0 and higher, although the bug report still lists that solution as "Upgrade to controller version 5.1.151.0 or higher".

I am 98% sure that I successfully set up and tested a chained SSL cert from GoDaddy for web auth on a 4.2.176.0 controller earlier this year because our cert provider stopped issuing unchained certs (I could very well be wrong!). From another reply in this thread, it looks like Geotrust still issues unchained certs, so that may be the quickest route for the OP.

The release notes for 4.2.176.0 indicate an open caveat:

CSCsq13174-Web authentication device certificates cannot contain the Certificate Authority (CA)

roots chained to the device certificate. However, device certificates should be able to be downloaded

as chained certificates (up to a level of two).

There is a new doc for loading chained certs on a WLC (it concurs with your 5.1.151.0 comment above, and it was updated in February of this year):

http://www.cisco.com/en/US/products/ps6366/products_configuration_example09186a0080a77592.shtml

[Robert.N.Barrett_2]

By the way - what older AP's do they have? If you delete the recovery image, even older 1200's will work with 5.2. From the release 5.2.178.0 notes:

Cisco Unified Wireless Network Solution Components

The following components are part of the Cisco UWN Solution and are compatible in this release:

• Cisco Aironet 1130AG, 1240AG, 1522, and 1524 Mesh Access Points

• Cisco Aironet 1100, 1130, 1140, 1200, 1230AG, 1240, 1250, 1300, and AP801 Series Lightweight

Access Points

Note This release does not support Cisco Aironet 1505 and 1510 access points.

[runningboy01]

They are running 1010 APs.

[runningboy01]

Ended up disabling HTTPS and enabling HTTP only. Also created ACL that denied access to HTTP to the address of the controller.

Doing this worked for the customer as they no longer get the Certificate error and I don't have to worry about security problems, as they are on a seperate VLAN anyway.