WLC cert to avoid the security warning page

[welleslee]

Hi guys,

I am doing some tests with installiing a 3rd party cert on a WLC to avoid the security warning page when trying to access the WLC through https, and I am following the following configuration example:

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

I have followed the same precedures given in the above document, and I am using windows CA to sign the CSR just for a test, I could install the final .pem cert successfully onto the WLC however I am still getting the same warning page when I was trying to login to the WLC through https. I have checked in my certificate store and I have trusted the root CA which is the windows CA in this case.

I have also tried to access the WLC from the CA server (windows 2008 box) still getting the same warning message.

so what should I do in order to make this to work with windows CA? did I missed something in the configuration?

Thanks in advance for your time and help.

Andy

[Nicolas Darchis]

You need to check what is the warning message complaining about.

One thing to note is that the CN of your certificate must be equal to the DNS name of the URL the clients are browsing to. This is configured in the virtual interface settings on the WLC. You can set the webuaht DNS name there.

But that hostname must be resolvable in the DNS server to "1.1.1.1" or whatever your webauth ip is.

[welleslee]

Hi Nicolas,

Thanks a lot for your reply.

I have generated another CSR using OpenSSL and this time with the CN name set the same as the virtual interface DNS name. However I am still getting the message "there is a problem with this website's security certificate" warning.

from the WLC, going to security --> Web Auth --> Certificate, I can see that under "subject name", the CN name is the same as the the one configured under the WLC virtual interface called "WLC2112", and I have one entry in the DNS server configured with the same name (WLC2112) with IP address 1.1.1.1 which is the same as the virtual interface IP address.

in the browser, I typed in https://WLC2112 and I got the certificate warning message as shown above.

now I am very confused with how this process really works. I used to set the name of the WLC (WLC2112) under the DNS server with the actually management IP address of the WLC, because I think by doing this, when we type https://WLC2112 in the URL it will resolved to the actual management IP address of the W:C which will bring us to the WLC GUI page.

Then I changed the IP address to 1.1.1.1 which is the virtual interface IP address, the problem now is that when I try "ping WLC2112", it always resolves the name to the management interface IP address of the WLC, even I have already changed the IP address to 1.1.1.1 in the DNS server.

so can you please explain a bit more on how this process actaully work? or is there any documentation on this? if I have the hostname "WLC2112" with IP address 1.1.1.1 configured under the DNS server, when i try to access the WLC by doing https://WLC2112, how does the browser know the actual IP address of the WLC since it will be resovled to 1.1.1.1?

Did I missed anything in my config?

Thanks for your time and help.

[Scott Fella]

You need to be able to resolve the FQDN. If you ping the CN name from a wired workstation, does DNS resolve the name? The DNS that the users get from dhcp will need to resolve this CN. Also you need to reboot after you add the DNS name in the VIP interface.

Sent from Cisco Technical Support iPhone App

[welleslee]

Hi Scott,

Thanks very much for your reply.

I did a reboot on the WLC after I made the change on the virtual interface.

This time I have tried to delete the entry in the DNS and added it back in again, I was trying to ping the CN name from the win server 2003 directly, however this time I got the message "Ping request could not find host WLC2112. Please check the name and try again", however if I do a "ping WLC2112.test" which is the full domain name, I can see it's getting resolved to 1.1.1.1. I am still confused on how does the browser know the actual IP address of the controller, since we configured it to be resolved to 1.1.1.1, not the actual management IP address.

maybe this is silly question but I don't have to reboot the windows server right?

is there anything else I need to configure?

Thanks.

[Scott Fella]

It's like if you go to a secure website like a bank. The computer gets a certificate and then tries to resolve that certificate. Seems like you only can ping when you use the FQDN. Is the FQDN configured on the VIP? As long as the device can resolve the FQDN that you set in the CN and the VIP you should be okay.

Sent from Cisco Technical Support iPhone App

[Nicolas Darchis]

Thanks for explaining Scott :-)

[Scott Fella]

Look at this doc. The CN is the host.domain

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

Sent from Cisco Technical Support iPhone App

[welleslee]

Hi Nicolas and Scott,

Thanks a lot for your help so far.... however I still could not get this to work properly...

here is a summary of what I have done:

* generate CSR from OpenSSL which installed on the win 2008 server, filled in the questions and make sure the common name (CN = WLC2112.mydomain.local)

* opened a browser for microsoft CA server http://127.0.0.1/certsrv, copy the CSR and paste under saved request with certificate template as "web server", submit and download the cert as DER encoded)

* convert the CER file downloaded to PEM format

* combine the pem file with private key and covert to the final PEM file as indicated in the documentation

* transfer the PEM cert to the WLC and reboot the WLC

* on the WLC, configured virtual interface DNS name as "WLC2112.mydomain.local", also on the DNS server (win 2008 server) added an entry of WLC2112 with IP address 1.1.1.1

=========================

now when I try to access the WLC GUI from the local server (win 2008 server), I got the following:

There is a problem with this website's security certificate.

The security certificate presented by this website was not issued by a trusted certificate authority.

The security certificate presented by this website was issued for a different website's address.
Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.

We recommend that you close this webpage and do not continue to this website.

so is there anything I missed out in the configuration?

also another quesiotn is that do we access the GUI by typying the IP address of the WLC or the name configured in DNS? sometimes we have https://WLC_name to access the WLC GUI, does that mean I need to configure another DNS entry for the WLC to resolve the name for the actual IP address of the WLC? e.g. WLC2112_link as DNS entry and assign IP address 192.168.101.111 (actual IP address of the WLC management interface)

Thanks very much for your time and help.

[Nicolas Darchis · Accepted solution]

There are 2 different separate things :

1) The name you can put in your browser to go and manage your WLC configuration. This is simply something you configured in your DNS server to point to the WLC management ip. That's about it

2) The name you configured in "virtual interface dns hostname" on the interface settings of the WLC and that you also added to your DNS pointing to 1.1.1.1

When this is done, it simply means that, when a guest is connecting, instead of redirecting it to http://1.1.1.1/login.html, the guest is redirected to http://mywlc.domain.local . Then the guest asks the DNS who that is and ends up anyway contacting 1.1.1.1 (which is the webauth page). The only advantage of this process is that the certificate name can be verified with the webauth dns hostname.

So that's 2 different hostnames for 2 different ip addresses and 2 different usage.

With regards to the error you still have. That's because you issued your certificate from your microsoft CA which your guests are probably not trusting ? You need to add the root CA certificate on every client ... Otherwise that would mean that clients trust anyone as long as it's a certificate, which is not so secure :-)

[welleslee]

Hi Nicolas,

Thanks for your detailed explanation, that does make a lot more sense now.

I think I finally got this to work... I did not get the warning page when I was trying to access the WLC which got the cert installed, and confirmed that I do have this warning page when I try to access the other controllers.

however the strange thing is that it works when I was trying to access through firefox, but it does not work with windows IE. I believe I have already downloaded the root certificate from the CA and installed on the local machine, and I have checked the cert store from tools --> internet options --> content --> certificates and I could see  the cert issued by the CA, however not sure why this is not working only on windows IE.

but anyway, I believe I got the idea now and once again thanks very much for your help.

also thank you scott for your time and help as well.

[Scott Fella]

You need to make sure the certificate is in the machine trusted root CA folder.  So if you go to start | run and type mmc and then go to file | add/remove snap-in and then choose certificate then choose computer account then hit next then hit default is local computer then hit finish.  The certificate you put on the WLC has to be imported if not already located in the Trusted Root Certification Authorities... Certificates folder.

[welleslee]

ok guys.... I was wrong last time... actually after double check again it was NOT working .... I think i just simply trusted the cert last time when i was using firefox....

I have tried a number of different things and double checked the places that mentioned previously in this thread however I could not pick up anything wrong in particular, although I know there must be something I have missed out.....

so this time I have also read through some other references on the web, and found the following:

http://www.my80211.com/home/2011/1/16/wlcgenerate-third-party-web-authentication-certificate-for-a.html

I think I did very similar config and only difference is that I am using unchained cert.

I have double checked the following:

• on virtual interface configuration, I have ip address 1.1.1.1 and DNS host name as "wlc2112.mydomain.local"
• from the controller GUI --> Security --> web auth --> certificate, under subject name, I have CN=wlc2112.mydomain.local, however under Issuer name, I have CN=mydomain, this is a bit different from the last screen shot in the above link. could this be a problem?
• in windows 2003 server, with DNS server I have a field called "wlc2112" with IP address 1.1.1.1
• as mentioned by Scott previously, I went to the mmc certificate snap in, and under trusted root certificate authorities, I have installed the WLC cert there and I could see it there as well.

now if I try to access the WLC GUI from here I am still getting the error message same as the one below:

http://www.vistaclues.com/the-security-certificate-presented-by-this-website-was-issues-for-a-different-website%E2%80%99s-address/

I then followed the instruction and continue to the website, and when I go file --> properties --> certificate, it actually shows the certificate is issued to 169.254.1.1 and issued by 169.254.1.1, with a red cross on the cert itself....... I have no idea where is this come from, so I just want to ask when I try to access the WLC GUI through a web browser, after I type in https://wlc-ip-address, how does the browser know / search for which certificate it needs to look into? I think in my case here it clearly points to the wrong certificate?

also on the server I went to http://127.0.0.1/certsrv and selected "download a CA certificate, certificate chain or CRL" and then "install this CA certificate chain", does this mean I acknowledge to trust the root CA by doing this?

I am not sure what I have missed out but it just does not work for some reason... is there any other places that I need to check/verify?

Sorry for the long writing but any comments would be highly appreciated.

Thanks in advance for your help.