Certificate problem (webauth and WLC/WCS login pages)

Unanswered Question
May 4th, 2007

Hello,

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!

Thanks,

Jeff

P.S. My WCS is version 4.0.97.0 and I just upgraded my WLCs to 4.0.217.0 with plans to upgrade to the new 4.1.171.0 in the next week.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 5 (3 ratings)
jpeterson6 Fri, 05/04/2007 - 10:17

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?

Thanks,

Jeff

ericgarnel Fri, 05/11/2007 - 05:27

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/

ericgarnel Fri, 05/11/2007 - 05:31

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

jpeterson6 Fri, 05/11/2007 - 05:38

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?

ericgarnel Fri, 05/11/2007 - 06:03

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.

rlaplante@hro.com Wed, 05/16/2007 - 09:00

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

this:

---

Text in the Browser Window

Scott Fella Wed, 05/16/2007 - 18:50

I have the same issue. I was looking a the cert gererated by the WLC and the CN=1.1.1.1 which is the VIP. When I try to CSR from VeriSign, it does not like the 1.1.1.1, it ask for a fully qualified domain name.

nichnw Thu, 05/24/2007 - 14:37

In the controller web interface, go to Controller -> Interfaces, and edit the VIP. You'll see an entry for a hostname. Give 1.1.1.1 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

None

Symptom:

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.

Workaround:

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.

aalton Fri, 08/10/2007 - 08:06

Entrust offers standard SSL certificates that do not require the intermediate chain.

nichnw Fri, 08/10/2007 - 08:08

We ended up getting a single-root cert from RapidSSL. There are not many that offer them. Adding your suggestion, I now know of two!

Thanks!

fernandess Thu, 09/06/2007 - 10:07

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 1.1.1.1? I want to be sure before I purchase one. Thanks.

nichnw Thu, 09/06/2007 - 10:32

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 1.1.1.1 from the DNS that serves the guest clients.

jpeterson6 Thu, 09/06/2007 - 10:35

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.

fernandess Thu, 09/06/2007 - 12:22

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 1.1.1.1 (not the FQDN) so I see 1.1.1.1 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!

nichnw Thu, 09/06/2007 - 12:31

Yeah, since no hostname existed when it auto-generated the cert internally, it just used the 1.1.1.1.

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 :)

fernandess Thu, 09/06/2007 - 12:54

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.

fernandess Thu, 09/06/2007 - 16:13

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)

vincent.kilchoe... Wed, 09/12/2007 - 05:48

Hi,

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

Result :

Now the users are not redirected. Into the browser I can see http://wlc.domain.com/redirect_url instead of https//1.1.1.1/redirect_utl.

Do I need to enter the FQDN with IP 1.1.1.1 into the users's DNS to solve my problem?

Best regards,

Vince

Now

jpeterson6 Wed, 09/12/2007 - 06:07

Hello Vince,

It looks like everything is working normally.

Just to be sure though, what hostname did you give your virtual interface?

Regards,

Jeff

vincent.kilchoe... Wed, 09/12/2007 - 06:36

Hi Jeff,

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?

Vince

jpeterson6 Wed, 09/12/2007 - 06:51

Hi Vince,

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.

vincent.kilchoe... Wed, 09/12/2007 - 09:12

Hi Jeff,

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.

Conclusion:

It seem that I need to put the 1.1.1.1 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...

Actions

Login or Register to take actions

This Discussion

Posted May 4, 2007 at 6:09 AM
Stats:
Replies:23 Avg. Rating:5
Views:1442 Votes:0
Shares:0
Tags: No tags.

Discussions Leaderboard