In addition , There is a customize Web authentication page.. We have 2 clients accessing this page through public wifi...Firefox /Chrome shows warning of non secure site and after accpting the condition.It takes you to web. But with IE ...it doesn't work.. Doesn't show warning page and simply shows the error HTTP 405 method not found.
Wlc 5508 version 7.116
IE 7 and IE 8 ( Both version not working)
Sounds like an IE problem. There's nothing you can do on WLC side anyway.
If the web page is custom, maybe it contains funky elements ? Did you try to set back the normal internal page and see if IE works ? If yes, then it's something in the HTML of your custom page.
Also check the IE settings and policies. I've seen some IEs that were configured to only do SSLv2 and not v3 or TLS which is utterly not-smart.
Guess What ! ..
Issue is resolved by rebooting laptop with IE 8.. No more 405 Error Message and its browsing with no issues.
I guess rebooting the devices is mother of all solutions !
Appreciate your response.
I have seen this issue before if you have some of the web security features enabled in IE. I have 1 client that you have to add the ip address to the trusted addresses and the problem goes away. '
I have only ever seen this in IE.
IE users are not able to login via web authentication and customized page, WLC version 184.108.40.206. Sounds exactly like the problem we had.
Do you use a 3rd party certificate for HTTPS access of the login portal issued by an intermediate CA?
In our case the problem was with the 3rd party certificate issued to the login portal. I only installed the certificate for our login portal instead of the whole chain (+intermediate CA, Root CA). Thus I seem to have forced IE users to rely on the MS cert store, which the IE also uses. To my knowledge all the other browsers have an own cert store.
Most notebooks will have all known root CAs installed in the MS cert store, but not many Intermediate CAs. Whenever the user now got redirected to the web auth login page the certificate check failed, as the intermediate CA was not installed in the cert store.
I tried the possibility to manually install the intermediate CA. This helped to get IE users access to the login portal. However this is not a feasible and scalable solution as one cannot roll out this intermediate CA to guests of the company.
Also most 3rd party certificates have an AIA element to fetch the certificate path from the dedicated URL within, if the cert store does not contain the whole chain. But as any access to the internet is prohibited by the WLC until the user has been authenticated, this possibility also fails unless one configures a pre-auth ACL.
However I would not recommend this as you would have to define whole IP ranges to allow access to the URL, where the certificate path is contained. I then tried to solve this problem by installing the whole chain now, putting all relevant certificates together (login portal certificate, intermediate CA certificate, root CA certificate) and installed it on on of our WLCs.
Here is a guide on how to do that:
We have received feedback from our users conntecting through that WLC that the issue was not visible anymore.
I'll soon roll out the merged certificate on the other WLCs.
During the whole troubleshooting process I only wondered why the IE was not doing the default action and just show a web page, where it says the site is not trusted instead of not connecting to it at all. I suspect it must have been on of the several updates.
Added guide for chained certificate installation