There's a mobile version of our website.
When I try to web in to the WCS or the WLC controls I get a message saying that the certificate could not be verified. I can add it into the trusted CA on IE6 but the message will still pop up anyway. It also says "The name on the security certificate is invalid or does not match the name of the site".
This problem is also happening for the WebAuth login page. This is more critical for me, as we have two WLANs which require WebAuth. When the clients use IE6 or Firefox it's not an issue, but when using IE7 it seems to randomly drop their connection due to the certificate being viewed as 'invalid' by the browser, forcing them to reauthenticate. I need to get this figured out and resolved so that the wireless webauth network is more reliable - I can't expect people to not upgrade to IE7.
Has anyone managed to get through this problem without purchasing a valid certificate from a CA like Verisign? Let me know please!
P.S. My WCS is version 220.127.116.11 and I just upgraded my WLCs to 18.104.22.168 with plans to upgrade to the new 22.214.171.124 in the next week.
I've done some more research on how IE7 handles certificates and it basically comes down to the fact that the hostname of the certificate doesn't match the hostname of the server it's trying to connect to.
Makes sense, but I can't figure out how to do this through WCS/WLC. I'm unable to find anything on this in the documentation. Any pointers?
You have two options.
You can either purchase a valid cert or gen a root cert using your own CA and then install the root cert on the clients' computer.
there are some settings in IE7 that you can change to make it more tolerant of invalid certs. I don't exactly recall where in iE7 to do it.
check out https://www.openca.org/
Forgot to mention...
We ditched the webauth page in favor of using a captive portal solution instead. We use pfsense, which is a fork of monowall. the splash page is served up on port 80, no ssl involved.
Ours is a guest environment where all the users are treated as guests on the network
Thanks for the information. I have a question though..
Since the webauth redirects into a virtual IP, will the webauth cert need to have that IP as it's 'hostname' in order to be valid? Or just the name of the controller?
As for your suggestion on the other form of authenticating, I can't use an all-guest network here unfortunately - I'm in an education environment so I need dedicated SSID's for students, employees, public access, etc. They all have different settings and bandwidth limits.
Would your auth-page method still work under those conditions?
Not sure on the 1st question, think the name of the controller.
Re: alternates: Both monowall & pfsense support builtin radius auth and/or can auth against other radius servers (freeradius, IAS, steel belted...)
Given your environment, I am assuming that each group has it's own subnet?
Here is how we do it:
wireless subnets ---> policy routers ----> captive portal.
the policy routers perform traffic shaping, ip nbar for proto discovery, service policies to throttle p2p, bittorrent, youtube, myspace, down to a trickle and then route maps to direct only https, http traffic through the portal and the rest out thru firewalls.
We do the route maps to better support multiple vpn clients behind nat. You may not need to use route maps in your situation.
Recieved this from TAC which may play into your issue.
The description of the Microsoft post-login bug is as follows but we have the code with this fix in the attached:
There is known bug filed with Microsoft in reference to the tag. There
is also one with Netscape. The work-around is below:
The Pragma statement fails in IE because of the way IE caches files.
There is a 64K buffer that must be filled before a page is cached in
IE. The problem is that the vast majority of the pages using the Pragma
statement put it between the HEAD tags.
The HEAD loads and the Pragma comes into play. The browser gets the go
ahead to not cache the page, however there is not yet a page to not
cache. Since the page hasn't filled the 64K buffer, there's no page so
the Pragma is ignored. Thus...the page is cached.
The solution is to play to the buffer. If you're really serious about
the Pragma working, place another set of HEAD tags at the bottom of the
document, before the end HTML tag and re-enter the Pragma. This is a
suggestion straight from Microsoft Support. The page would look like
<META HTTP-EQUIV="Pragma" CONTENT="no-cache"> </HEAD>
Text in the Browser Window
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
I have the same issue. I was looking a the cert gererated by the WLC and the CN=126.96.36.199 which is the VIP. When I try to CSR from VeriSign, it does not like the 188.8.131.52, it ask for a fully qualified domain name.
In the controller web interface, go to Controller -> Interfaces, and edit the VIP. You'll see an entry for a hostname. Give 184.108.40.206 an entry in DNS, and then use that name in this field.
However, you will probably then run into the next problem using a certificate.
CSCsh18356 Bug Details
3rd party chained authentication certificates
The CCO documentation to install a 3rd party certificate on the WLC do not mention an intermediate
certificate, nor is there any -chain option in the recommended commands.
1. Acquire an unchained cert from CA (meaning signing root is trusted).
2. Use external web-auth server which does support this optional feature.
3. Have all valid intermediate CA root certs (trusted or untrusted) installed on the client.
All of VeriSign's certs have intermediates now, and the WLC doesn't support them. I'm going to see if VeriSign can issue a cert from the root. If not, I guess I'll have to find a SSL cert vendor that will.
I am dealing with this issue as well. So just to be clear, the single-root cert from RapidSSL allowed you to issue the cert to 220.127.116.11? I want to be sure before I purchase one. Thanks.
The cert is issued to the fully-qualified domain-name, not the IP, so it isn't an issue.
We have a valid host/domain name for the device/cert, and it resolves to 18.104.22.168 from the DNS that serves the guest clients.
I also got verification from Cisco that the DNS name/FQDN for the virtual IP does not have to be publically registered on the DNS servers. As long as the name is configured on the WLC's it'll work.
Thanks so much for the quick responses. You guys rock. I think one of the reasons for my confusion was that the existing cert was issued to 22.214.171.124 (not the FQDN) so I see 126.96.36.199 in my browser (not wifi.x.edu). This made me think I needed the IP in the cert, but I'm assuming it will redirect to wifi.x.edu once I have a 3rd party cert issued to the FQDN. Thanks again!
Yeah, since no hostname existed when it auto-generated the cert internally, it just used the 188.8.131.52.
BTW, I was going to mention that RapidSSL will let you trial a fully functional cert for 30 days for free, no strings attached. If you like it, pay the $ and get the one for the year. Its a little less scary to experiment with when its free :)
Cool, thanks for the verification. That was kinda freaking us out until we actually looked @ the cert & figured that was the deal. I was aware of RapidSSL's 30-day trial cert and yes, it is MUCH less scary to experiment for free. I think they even knock off the price a bit if you use the trial cert. Again, thank you for the info. I think I've found more help here in an hour or two than a couple days drudging through Cisco's documentation.
Ok, so I got it working. Now I have another question as far as PDS's, Smartphones, etc. are concerned. From what I've seen & tested so far, they aren't supported with this cert because it's not on any of the root CA's that are installed on the mobile devices. It looks to me like the Power Server ID cert (the $500 one) is the only one that is supported. So my question is, is this true and if so, is the $500 cert unchained? Thanks (once again)
I use an external web auth server with a valid certificate. But when WLC redirect users, they have a message that the WLC certificate is self-signed. So I've done the following things :
I've generate my certificate (Cybertrust).
I've added a DNS hostname to the virtual interface
Now the users are not redirected. Into the browser I can see http://wlc.domain.com/redirect_url instead of https//184.108.40.206/redirect_utl.
Do I need to enter the FQDN with IP 220.127.116.11 into the users's DNS to solve my problem?
It looks like everything is working normally.
Just to be sure though, what hostname did you give your virtual interface?
Thank for your fast reply
I've gived the same FQDN on the certicate and on the virtual interface.
Do I need to put the virtual interface on the users's DNS?
Not quite sure what you mean here..
If you're referring to modifying the hosts file on the client machine, then no you shouldn't have to.
The redirect is working normally; it's just using the DNS hostname for the redirect/Virtual Interface on the URL now instead of the IP address, same as any other website.
Hope that helps.
I've made a trafic sniff with wireshark and I can find that my notebook try to resolve my fqdn to the DNS server.
To made test I've added manually the address / FQDN into the LMHost of the notebook and now it work.
It seem that I need to put the 18.104.22.168 and his FQDN into my internal DNS but I don't know why... Maybe this is because I use an external webserver for authentication of users...
Login to share your discussion activity with your friends on Facebook. You can control what you share and turn off sharing anytime.
Your Facebook friends can now see that you have started this discussion
Your Facebook friends can now see that you have commented on this discussion
Your Facebook friends can now see that you have read this discussion