Dec 12

How to avoid the certificate error with Cisco’s WLC internal Web Authentication

Have you ever visited a business and you were given a username and password for their guest wireless access, only to get an SSL Certificate error when it sends you to the authentication page? Is it safe or not?

On the Cisco wireless controller there is a layer 3 security feature called Web-Auth. When the authentication is set to Web-Auth the user attaches to an SSID, then when they open their web browser it forces them to a login screen. The user then has to enter a username and password. After authenticating the user is allowed to use the wireless network.

The default settings on the controller is to force the user to https://1.1.1.1 (1.1.1.1 would be the virtual address on the controller). When this happens, the controller uses a self signed certificate and there for it gives the end users a certificate error.


I recently tried to import a public certificate to my Cisco 5508 controller (Version 7.6.130.0) to avoid this error. After working with my coworker that manages the certificates, along with Cisco TAC, I found this to be a very difficult task. Every time I tried to import the certificate file it errored out. Later I found out from TAC that version 7.6 had a bug that didn’t allow a certificate to be imported. I was forced to downgrade to 7.4 to load the certificate. I did the downgrade, I didn’t lose my config as I expected. I imported the certificate on version 7.4. My APs are 3702s so they are not supported in version 7.4, I had to upgrade to 7.6 in order to test the certificate. After upgrading, I still got the error. We tried it again and it failed again. Each time we modified the certificate, downgrade, then upgrade. This process took a long time only to have it fail. I’m not sure what was wrong, but with our certificate guy and Cisco TAC, we couldn’t get it to work. The certificate error continued. We did indeed have an address on the virtual interface with a DNS Host name and the address was in DNS.

After some more research I found that I could change that authentication page from https to http. On the controller go to MANAGEMENT –> HTTP-HTTPS. The third item from the top is “WebAuth SecureWeb”, the options are enable or disable. Mine was set to enable so I changed it to disable. You then need to go to CONTROLLER –> INTERFACES –> VIRTUAL make sure the “DNS Hostname” field is empty. The IP address does not matter, 1.1.1.1 is very common. If you change the virtual address you will need to reboot the controller.

After changing the WebAuth SecureWeb to disable and rebooting the controller your guests can access and enjoy an authentication screen without the SSL certificate error.

Does it matter that it’s not secure? For a guest that is getting a random or shared username/password, I don’t think so. What do you think?

Dec 01

How to validate your Access Point location?

In the past I have preconfigured and marked the access points (AP) before giving them to the people installing them. My last install there were to many APs to preconfigure. I provided the cabling vendor with the location of each AP and what number that AP should be on that floor. I had explained that I needed to know the MAC of the AP for each AP number. I had the contractors mark the AP with a number before they installed them in the drop ceiling. When the cabling guys were done, they provided me a list of AP names and MAC addresses.


Based on the MAC I named the APs in the system, then placed them on the map. When I walked around, I noticed that AP 23 was where AP 5 was supposed to be. I was now concerned that the APs were in the wrong location and I wouldn’t know what AP was where. To validate the placement I used the Ekahau Site Survey software.

The facility I was in had three floors. I shut off two of the floors so I only had one floor of APs enabled. I then loaded a map of that floor plan into the Ekahau software. After adjusting the size, borders and survey area I was ready to do a survey. I walked around the floor performing the survey. There were many APs that I walked directly under and others that were in rooms off of the hallway that I could not get close to due to locked doors.

After finishing the survey the Ekahau software provided me a list of AP names and where it thought the APs were located. The Ekahau software correctly placed the APs that I was able to walk under. The APs that were in the locked rooms were off a little bit, but very close. The software allowed me to easily position the APs on the map in their correct location. After performing a couple physical checks on the APs, I felt that the AP placement in the Ekahau software was reliable.

Through this survey I was able to find a couple of the APs that I walked under were in the wrong location. It looked like the contractors got the APs mixed up because the APs were in backward locations.

The Ekehaue software saved me a tremendous amount of time validating the location of the new APs. I have a couple more buildings to install wireless in and I feel confident that I can rely on Ekahaue not only for coverage and signal strength, but for validating the AP placement also!!

I highly recommend the Ekahau Site Survey software to you.

What has your experience been with the Ekahau Site Survey software?