10-28-2016 09:57 PM
After connecting to a guest SSID with a captive portal, if a user is trying to go to an https site, the client/browser will likely throw the certificate error "err_cert_common_name_invalid". This is triggered due to strict checking because the SSL certificate on the Clearpass and the SSL certificate on the requested https site do not match.
Now I know the fix is to simply go to an http page so the certificate issue won't trigger upon the initial redirect to the captive portal. However I was wondering if anyone already found a better fix or a more creative workaround for this issue? We have an end-customer with a large campus and hundreds of guests and they regularly get questions about this. End-users will often mistakenly assume there is an issue with the wireless due to the certificate error.
For example, Apple made a workaround by implementing captive network assist so the user doesn't get the opportunity to open his browser but immediately gets the captive portal upon connecting to the SSID. This works great on mobile devices but I'm looking for a more global solution if possible. (preferably on Clearpass and not the client side)
Solved! Go to Solution.
10-29-2016 04:37 AM
Device makers need to step up here. Windows 10 should pop up the default browser and attempt to hit an http site which works great. Most newer Android devices have a captive portal browser.
10-29-2016 01:40 PM - edited 10-29-2016 01:53 PM
Thanks for the feedback Cappalli, I kinda guess I knew the answer already but I was hoping I was wrong.
We also tried enabling http redirection and this does fix the cert errors for some clients. However most clients are still getting the error, which makes sense of course. From a technical/security perspective, the error is a good thing however in reality it is rather annoying.
It is as you say though, device makers should step up. We are nearing 2017 and there still isn't a global fix for this rather simple problem. If Microsoft for example would make something similar like captive network assist, the problem would be fixed for 95% of the end users.
10-29-2016 01:53 PM
10-31-2016 02:02 AM
You can also check this blog post: http://community.arubanetworks.com/t5/Technology-B
One of the suggestions is to remove the redirect for HTTPS, which might be what you described (or not). That will at least stop the certificate warnings for other devices than Windows 10 and applications running in the background.
If you have urgent issues, please contact your Aruba partner or Aruba TAC.
11-02-2016 12:59 AM
The blog post explains the problem quite well however the workaround suggestions are pretty terrible. I guess we'll just have to deal with the certificate errors.
The author did speak about a new standard which is in the works, RFC7710. This seems like a very interesting solution but it will probably take a couple of years before being available.
11-02-2016 05:09 AM
Honestly, I wouldn't expect RFC7710 to ever see the light of day. There are serious security implications when using it which will likely result in OS manufacturers refraining from implementation.