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?

17 thoughts on “How to avoid the certificate error with Cisco’s WLC internal Web Authentication

  1. hi scape, I have been working on this certificate topic for a while on my WLC 5508/8500 environment. We have a big wireless network and I know what is the reason because you are getting this error. Give me a chance and I send you a note later today with a detailed explanation so you can evaluate your alternatives.
    Are you using webauth with external server or local in the WLC?

  2. In the following path of the WLC: security — > webauth — > certificate (I downloaded a SSL Certificate using the provided option), you install the WLC Certificate that would be used during the webauth process. The problem is this certificate cannot be signed by your internal CA Server (explanation below).

    We had the same issue here and that is why we had to request a WLC Certificate signed by a PUBLIC TRUSTED CERTIFICATE AUTHORITY (entrust, verisign, etc). It has nothing to do with the WLC Version (looks like the TAC Engineer was not clear about this).

    Your internal CA Server is not a PUBLIC Trusted Certificate Authority like Verisign or Entrust. So when you have a person from outside who tries to connect into your GUEST ssid, he will receive a certificate presented by the WLC which was signed by an Internal and Unknown Certificate Authority. This signature is compared internally by the iphone, android or laptop device against its internal Trust Root Certification Authorities and Intermediate Certification Authorities Database. (you can use MMC on your Windows laptop to verify this part) and because it is not in the internal DB list, you get the error message saying something like UNTRUST CERTIFICATE XXXXXX so you have to CLICK on ACCEPT EXCEPTION and TRUST on this Invalid Certificate.

    Even if you upgrade/downgrade your WLC, nothing would change.

    How we solved this?. We request only 1 certificate signed by a PUBLIC TRUSTED CERTIFICATE AUTHORITY which is common for all the WLC’s because the CN variable is the same for all the controllers (we have 10). I mean, the virtual interface (1.1.1.1) DNS HOST NAME value is the same for all the WLC’s. So when we created the CSR for all the WLC’s, the FQDN was the same for the virtual interface on all of them AND this unique certificate was signed by a PUBLIC Authority which is included BY DEFAULT in the Internal DB of all the external devices. So when the WLC presents this certificate, it would be valid for any guest user because is included by default on their laptop/smartphone DB as I mentioned before.

    Hoping this helps.

    regards

  3. Hi Scape,

    Sorry I went directly to the solution instead of analyzing your note in details. That is NOT a secure solution because you are only using HTTP (information including username/password is travelling in cleartext mode – it can be easily intercepted). You can minimize this problem by having POST instead of GET in the Login Page Html file (I have to check the source code in the default internal login page presented by the WLC in order to see what method is being used).

    However this is not a totally secure solution even if you were using POST).

    I am assuming you are NOT using an external server for the login page (that is my case). So in the SSID for Guest you should have in the Security — > Layer 3 — > WebAuth Type = INTERNAL.

    Disabling WebAuth SecureWeb, you are disabling the SSL/TLS protocol used by HTTPS which provides a secure 2 way certificate handshake (both ends MUST trust on the certificate presented by the other side) so if you are the enduser you can trust on the server providing the connection because you are not receiving a certificate error message from your browser (that means the server to which you are connecting is valid and you can trust on it). Otherwise, if you receive the certificate error message and CLICK on ACCEPT. you can easily be intercepted by a man in the middle impersonating an actual server and therefore collecting your sensitive data.

    This problem again has nothing to do with the WLC Software.

    If you removed the virtual interface DNS Host name, it should matter because you are not using certificates. I have not tried this part, I am gonna take a look on this when the DNS Hostname for the virtual interface is not configured. BTW, You should not have to change the virtual interface ip.

    As I said in my previous note, you have a proper solution for this certificate error message.

    The certificate that you see in the WLC: management — > http-https —> current certificate, is not the one being used for WebAuth. That one is located in Security — > WebAuth —- > Certificate.

    If you have another question, please send me a note, thanks

  4. correction at the end of my previous note.

    if you removed the virtual interface interface DNS Host name, it should NOT matter because you are not using certificates. However, I am going to check this part in my lab for local webauth using WLC default login page.

  5. Abraham, I did try using a public certificate. Maybe something went wrong in the openSSL part of it.

    I understand the web authentication via http is not secure and the username/password is going in the clear. Any guest that walks in would be handed the same username/password of the day. I do understand that a person close to the building could sniff that username/password, but they would only get public internet and nothing internal. I do understand the issues there too.

    It would be nice if Cisco would use the newer version of OpenSSL and make the process easier to get the certificate prepared and placed on the WLC.

  6. Hi Scape,

    I think your problem has nothing to do with the Openssl process or WLC version. the DNS Hostname of the virtual interface must be the same FQDN you use in the public certificate. In addition to that you need an entry in the DNS Server that you locally have with an entry to the 1.1.1.1 ip mapped to the DNS Hostname of the WLC Virtual Interface. It does not matter that ip 1.1.1.1 is not routed.

    On my case, I have 1.1.1.1 and also an entry in our DNS = 1.1.1.1 wifi.abc.com. I do not need to route that 1.1.1.1 because is local to the WLC.

    My suggestion is to reenable the WebAuth HTTPS in the Management part of the WLC, verify that the certificate is loaded in the WLC in the security — webauth — certificate, configure the virtual interface with the ip 1.1.1.1, configure the DNS Hostname of the virtual interface, create an entry in the DNS 1.1.1.1 wifi.abc.com where wifi.abc.com MUST be the same FQDN that you used in the CSR for the WLC Public cert.

    Hoping this helps.

    thanks

  7. btw, you initial question was: “is my solution secure?”. What do you think.

    That is why I answered saying NO and give you some reasons.

    Just to be sure, have you tried testing by yourself the guest connection using a Windows device (laptop)?. Did you get the same error message??

    I am asking this because I found from my own experience that the certificate created and installed in the WLC could be perfect and the issue is basically that some laptops and even smartphones DO NOT have the Trusted Certificate Authorities & Intermediate Trusted Certifiate Authorities lists installed

  8. Hi Scape,

    I suggest you to use the public certificate and check the FQDN of the WLC in that certificate and see if it matches the DNS Hostname configuration that you had in the WLC, independently of the virtual interface IP which you said has an entry in the DNS.

    After doing this, check in your windows laptop — mmc tool, if you have in the trusted certificate authority and intermediate trusted authorities folder for your computer account and user account, an entry for the public CA that signed you cert.

    Create a guest test and try again. It should work.

    I will post here my cnf file and share with you what fields of this file I modified in order to create the unique CSR for all the WLC’s.

    I have been using Openssl for my Cisco ISE’s-7 devices (EAP-TLS and HTTPS Management) with no issues including SAN Certificates so I do not need to create an entry in the DNS if I want to https into the IP of the ISE.

    regards

  9. Great comments. Catch we have is that….for guest users we use external DNS like 8.8.8.8. We have to publish FQDN of virtual IP say 1.1.1.1 as abc.wifi.com to external DNS so when webauth goes over https there will not be prompt. Not sure if 1.1.1.1 is good idea….or should I try 192.168.x.y. Still not sure if our DNS guy will yell at us??

    To use same FQDN on all the WLC’s…step is to use openssl on windows machine and generate the CSR?

    • Hi Capt,

      Answer is yes. Use openssl to create the CSR but I just found that something else has changed so you can successfully installed the webauth certificate on the WLC at least for version 8.0.132.0 based on the following link:

      http://www.cisco.com/c/en/us/support/docs/wireless/4400-series-wireless-lan-controllers/109597-csr-chained-certificates-wlc-00.html

      However, that link DOES NOT explain properly ALL the steps you must follow so you get a certificate that actually can be imported into the WLC. In fact, I spent 2 hours trying to figure it out the “importing certificate failed” on the WLC

      Please follow the next:

      1.-Create your CSR using OpenSSL and signed it.

      2.-If you get a PFX file from your Trusted CA Authority, lets say Entrust, you must extract from that file the KEY.PEM file using the command:

      openssl pkcs12 -in CERT.PFX -nocerts -out KEY.PEM -nodes

      3.-Get your Intermediate CA Cert Intermediate.crt file and convert it into DER using OPENSSL:

      openssl x509 -in Intermediate.crt -out Intermed.der – outform DER

      4.-Convert your intermediate.der file from previous step into .pem format using the following:

      openssl x509 -in Intermed.der -inform DER -out Intermed.pem -outform PEM

      5.-Repeat the same steps 3 and 4 above for your ROOT CA Cert that you have in .crt format

      6.-Repeat the same steps 3 and 4 above for your WLC Cert that you have in .crt format

      7.-Create an ALL-CERTS.pem based on the following sequence
      ——BEGIN CERTIFICATE——
      *Device cert*
      ——END CERTIFICATE——
      ——BEGIN CERTIFICATE——
      *Intermediate CA cert *
      ——END CERTIFICATE——–
      ——BEGIN CERTIFICATE——
      *Root CA cert *
      ——END CERTIFICATE——

      The file called ALL-CERTS.pem would look like this (NO blank space between each portion or certificate):

      —–BEGIN CERTIFICATE (WLC CERT)—–
      MIIFOTCCBCGgAwIBAgIEUNORQTANBgkqhkiG9w0BAQsFADCBuj—–END CERTIFICATE—–
      —–BEGIN CERTIFICATE (Intermediate CA CERT)—–
      MIIE/zCCAegAwIBAgIEUdNARDANBgkqhkiG9w0BAQsFADCBsDELMAkGA1UEBhMC
      —–END CERTIFICATE—–
      —–BEGIN CERTIFICATE (Root CA CERT)—–
      MIIEkTCCAIBAgIERWtQVDA
      —–END CERTIFICATE—–

      8.-COMBINE the ALL-CERTS.pem file created on step 7 with the KEY.pem file extracted on step 2 above using the following in order to configure a PKCS 12 file which is the final CERT for WebAuth in the WLC):

      openssl pkcs12 -export -in ALL-CERTS.pem -inkey KEY.pem -out ALL-CERTS.p12 -clcerts -passin pass:PASSWORD -passout pass:PASSWORD

      WHERE the PASSWORD is the secret word for the KEY.PEM file you received from your Trusted CA Authority that signed the CSR on step 1.

      9.-FINALLY, convert the PKCS file created on step 8 into PEM so the WLC can recognize it. Use the following:

      openssl pkcs12 -in ALL-CERTS.p12 -out WLCFinalCert.pem -passin pass:PASSWORD -passout pass:PASSWORD

      WHERE the PASSWORD is the same indicated on step 8.

      Hoping this helps.

Leave a Reply