One of my coworkers discovered a strange problem with two newly installed Cisco’s 3504 Wireless Controllers. Both Wireless Controllers are running in a failover (SSO) setup. When the Primary Unit is active, the WebUI of the Wireless Controller at the management IP is reachable. When the failover is switched to the Secondary Unit, the WebUI at the management IP was gone and only a login with SSH (and HTTP) was possible.
To check the problem I logged in into the WLC and verified the redundancy summary:
To check what services are running on the Secondary Unit, I did a port scan with nmap. As shown in the nmap scan output, the port TCP/443 for the secured WebUI (HTTPS) is closed.
To compare the scan result with the Primary Unit (where the secured WebUI was working) I did a redundancy force-switchover, which restarts the Secondary Unit and makes the Primary Unit the active one.
A nmap port scan against the management IP (in this case the Primary Unit), the scan result shows now that the port for TCP/443 for the secured WebUI is open. The WebUI in a Browser is responding as well and showing the login dialog.
Because TCP/443 on the Secondary Unit was shown as “closed” in the nmap port scan, my assumption was that the certificate required for HTTPS was not generated or that the secured WebUI was not enabled. A check with show certificate webadmin showed that on the Secondary Unit no certificate was generated or present.
Therefore I created a self-signed certificate on the Secondary Unit and enabled the secure WebUI as shown below.
A switching between Primary Unit and Secondary Unit shows now that both Units are responding to the secured WebUI at TCP/443. My assumption is that when a PKI-signed certificate is rolled out on the Wireless Controller, both Units get synced and use the PKI-signed certificate. (Not tested yet).