Solved: Wireless Guest CA Certificate problems

lburke · ‎12-04-2008

Hi Guys,

I have a problem with the Guest CA certificates. I'm running 5.1.151.0 code. Wwhen I try to upload a certificate from Comodo (and reboot the controller) I still get the 'There is a problem with this website's security certificate' message in IE7 and similiar in Mozilla.

When I view the certificate on a client machine, I'm informed that the certificate cannot be verified up to a trusted certification authority.

If I look at the cert issued to me, I can see the certificate chain - i.e.

WLC Cert -> EssentialSSL cert -> Comodo Root cert. However these dissapear (or can't be seen) when I view the cert from the client machine.

The Comodo Root cert is there in my 'Trusted Root Certification Authorities' on the client, but the EssentialSSL imtermediate isn't.

I have read somewhere that version 5.1.151 can use chained or unchained certificates, which one should I be using?

When I get the certificate from Comodo, included are a number of other certificates:

192_168_22_1.crt

AddTrustExternalCARoot.crt

ComodoUTNSGCCA.crt

EssentialSSLCA_2.crt

UTNAddTrustSGCCA.crt

the 192.168.22.1 is the virtual IP of the wlc (I didn't use DNS for a reason).

Any ideas?

Liam Burke.

grzegorz.ciolek · ‎12-04-2008

Hi,

One note to chained certificate in 5.1.x. It must be merged in single pem file. Do not ask me how. I have not do this by myself. I have seen this tip on TAC case clection or somewhere else.

Cheers

Gregory

View solution in original post

Scott Fella · ‎12-04-2008

I always use a root CA cert. Even though 5.1 supports chained, I have never tried it, since using a root is easy. The CN that you use to generate the CSR needs to be entered on the VIP interface and you need to resolve that CN to your VIP which is 192.168.22.1. I use RapiddSSL for most of all my SSL certs.

-Scott
*** Please rate helpful posts ***

lburke · ‎12-08-2008

I spoke to our local SE here, and he got me a great document on how to combine the chained certificate prior to uploading the cert to the wlc.

Basically, open up the device cert, the intermediate CA cert and the Root CA cert using notepad or equivalent, and copy and paste them all into one file, like so:

------ BEGIN CERTIFICATE ------

*device certificate*

------ END CERTIFICATE ------

------ BEGIN CERTIFICATE ------

*intermediate CA certificate*

------ END CERTIFICATE ------

------ BEGIN CERTIFICATE ------

*Root CA certificate*

------ END CERTIFICATE ------

I then combined this with my private key, (last step in the guest cert doc) and uploaded the cert to the Guest Controller.

The best thing here is that I was able to get a cert issued by Comodo to the IP adress of the virtual interface (192.168.X.X) and I didn't need to punch a hole in my firewall to allow DNS to the corporate DNS server to resolve guest.somecompany.com to the IP. Also I didn't need to use a private IP on the virtual interface which resolves on the internet to guest.somecompany.com.

Thanks to all who got back to me,

Cheers,

Liam

dhirajgrover · ‎01-22-2009

Liam,

Is there a way that you could email this document to me? I am in the same situation (problem) with the installation of the cert on the WLC.

Thanks,

Dhiraj Grover

dhiraj_grover@rcomext.com

lburke · ‎01-22-2009

no problem, I'll dig it out.

Liam

grzegorz.ciolek · ‎12-04-2008

Hi,

One note to chained certificate in 5.1.x. It must be merged in single pem file. Do not ask me how. I have not do this by myself. I have seen this tip on TAC case clection or somewhere else.

Cheers

Gregory

lburke · ‎12-05-2008

Nice one Gregory, I'll dig a bit deeper into the tac.

With regards the CN and DNS, I find it's a bit of a clunky solution. If I leave the DNS name blank, and just use the IP (i.e. use the IP in the CN portion of the CSR) and once it's not a publically routable IP then the cert will be issued by Comodo.

It saves using a public IP on the virtual interface, and either: getting the hosting company to publish a dns entry for 'Guest.Company.Com' to the whole of the internet, or punching a hole back through the firewall to the internal DNS servers which I percieve could leave the DNS servers open to DOS attacks etc.

Liam