11-22-2017 03:15 AM - edited 07-05-2021 07:54 AM
WLC 2504, AireOS 8.0.152.0
ISE 2.1 with CWA redirect
Client Android Samsung S4 and iOS iPhone 6s
Problem is, that WLC trying to intercept https redirected session with SSL certificate issued to its virtual interface 192.0.2.1.
And nowadays end points do not accept it and deal it as man-in-the-middle-attack.
So when I do ISE BYOD onboarding on android, i have problem to get redirection from https sites, and also have problem to access play.google.com for Cisco Network Setup Assistant download.
NET::ERR_CERT_AUTHORITY_INVALID
How should I command wlc to do not intercept https traffic with its own certification?
thank you for any advice.
11-22-2017 06:33 AM
Did you try to enable https redirection ? if not then give a try.
config network web-auth https-redirect enable
Check this:
Regards
Dont forget to rate helpful posts
11-22-2017 07:00 AM
Yes, I follow design guide and also this document.
But instead use local web-auth I am using CWA on ISE.
Dual-SSID BYOD.
Web Auth CMCC Support ...................... Disabled
Web Auth Redirect Ports .................... 80
Web Auth Proxy Redirect ................... Disable
Web Auth Captive-Bypass .................. Enable
Web Auth Secure Web ....................... Enable
Web Auth Secure Redirection ............... Enable
Fast SSID Change ........................... Enabled
11-25-2017 04:54 PM - edited 11-25-2017 04:57 PM
Due to the impact on performance and the usability issues like you described, it is actually recommended to keep https redirect disabled. You can undo this behavior with the "config network web-auth https-redirect disable" command. It is some time ago that I have worked with ISE's on-boarding procedure and I'm not trying to scare you, but I foresee another issue when you perform this change.
The challenge you might run into is that, since you have the "captive-bypass" feature enabled, Apple iPhones and iPads won't automatically launch their "mini browser" anymore to open the portal page. This means that users themselves need to open their (regular) browser and manually request a random webpage; big change that will be a https only webpage which will no longer be redirected by the controller. Disabling the "captive-bypass" feature won't help since those same iPhones and iPads won't post their agent information when using the "mini browser", making the on-boarding procedure stop (unsupported device).
Like I said earlier my experience with this on-boarding procedure is a little rusty, but it seems that Cisco has been working on this topic in the meantime. In this document the different options to tackle this issue are documented and also this topic might be informative for you as well. Keep us posted on your findings and good luck!
Please rate useful posts... :-)
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide