Firstly, I do apologise as this question has been posted in another forum, I believe it is the wrong one though hence me posting here.
I am running with a pair of Cisco 5508 controllers with 22.214.171.124 installed. We offer a guest Internet service to our user base and guests. To access the guest service a user must first authenticate via an externally hosted server, I won't go into the specifics but it is a secure service will a valid, signed cert for the login page. The issue I am hitting is that when a user logs into the portal the controller cert is then displayed (126.96.36.199) which returns a cert error. It kind of makes the service look insecure when it isn't. I've read numerous articles about creating CSRs, etc and loading certificates on the controller, but the issue we have is that we use externally hosted DNS servers for the service and they are refusing to create a DNS record. We can't use internally hosted DNS servers as this breaks our security policy. Is there any other way around this or do I just have to have the user accept the cert error?
It's always a best practice to install a self signed certificate on the WLC to get rid of these errors. Else, you will get these unnecessary cert error.
There is a couple things to look at. If you want to just get rid of the certificate error, well in v7.4, you can just disable WebAuth SecureWeb under the Management | HTTP-HTTPS Configuration. You can always purchase a 3rd party certificate and still use https if you want, but you will have to be able to resolve the FQDN of the certificate to the VIP of the WLC. If the guest users get an external DNS, what you can do is create a certificate and create a FQDN of something like guest.<your external domain> and then create an A record to relove that to one of your public ip address. Then on the VIP interface, you would set your VIP to the public address and then also enter the FQDN there.
First of all thanks for taking the time to respond to my query.
Regarding your suggestion to disable the setting, when I did this none of my APs would join the controller. We use the MIC certificate for APs joining the controller, so I'm guessing it is related to this. Got to do a bit of reading up but wanted to provide some feedback in the meantime.
Going to spend a bit more time looking into your other suggestion.
This has nothing to do with using MIC or not. I too use that default setting and have WebAuth Secure disabled and my AP's after being reset joins right back.
I hear you and I was under the same impression. If I go through the steps I followed maybe it can be explained..
Upgraded the primary controller from 6.0.x to 7.0.x a, APs upgraded. Upgraded FUS to 1.9. Upgraded controller to 188.8.131.52, upgraded APs. APs joined the controller. Disabled WebAuth Secure Web. Followed same steps for secondary controller. Shutdown primary controller to test failover to secondary. APs did not failover. Waited 15 mins, debugged CAPWAP and saw nothing coming in. Brought primary back online, waited 15 mins, debugged CAPWAP and saw nothing coming in. Waited a further 15 mins. Still no APs joining. Enabled WebAuth Secure on the primary, and boom, all the APs joined the primary. Not sure if this was just a coincidence, but this was the behaviour I witnessed. I'm running a pair of 5508's.
I've not witnessed this before, but this is the first time I've disabled this setting. Understand it has nothing to do with APs joining and may just be a coincidence, but this is what I experienced. I ran out of time during the change window so couldn't test this further and try to simulate again, will try again when the next window becomes available.
I have that same setup running at a few clients with no issues. So the best way is to just get a 5 year SSL cert and be done with it:)
Ok, will look into this.
Just one last question regarding the above, having read a few other posts regarding this topic, when the WebAuth SecureWeb is disabled and working as you have suggested, and you redirect to an external web page, does the controller instead use HTTP and present the login page i.e. http://184.108.40.206/login.html or does it redirect without presenting this login page? What I'm trying to avoid is the 220.127.116.11 login page coming up using HTTPS or HTTP, I was hoping to just redirect to the external and that would be all the user/client machine would see. If this can't be avoid a certificate it will have to be :)
It will be just http and it will show the VIP address your WLC is defined for. In order to not show this, you would need a 3rd party cert and the DNS the guest users obtain from DHCP, needs to be able to resolve the FQDN you specified in the certificate creation. You also define that FQDN in the VIP interface.