Security

On clearpass 6.4, captive portal url redirection does not work properly, some browser will show this error

"err_cert_common_name_invalid".  On client browser captive portal does not load or browser stuck in loading... In safari its the mobility controller's certificate which is shown on the client and will cause an error since the page url is https://cppm.domain.

 

 

 

If the site you are trying to go to is an https site, thus will always happen because the SSL certificate on the controller and the SSL certificate on the https website do not match. If that is what is happening, there is not a real way around that. Try going to a non-https site to see if that is your issue.

You mean ssl certificate on clearpass..

 

There must be something wrong on the way mobility controller handle the url redirection logic.  When user will type https://domain.com, controller will "hijack" the request and returns back to the client browser, clearpass captive portal, https://cppm.com . In clearpass side, it will just receive the request and will reply to the https request.  

Without knowing anything specific more than what you were saying, both the controller's SSL certificate and the ClearPass SSL certificate are involved in the redirect.  They both have to be (public) certificates trusted by the client to be seamless....  If the page the client is initially requesting is https (https://www.yahoo.com), that could potentially create an issue.

 

We could be talking about two things:

1.  Initial Redirect when the client first opens the browser 

2.  After the client clicks on submit for their credentials.

 

Which one are you referring to?

 

Initial redirect. Then again, the logic on url redirect should be...anything the user want to browse to , this is on the initial request, should be "hijacked" and replaced with "https://cppm.com"

If the initial request when the client is opening the browser is an https site, there will be an error because the site we are redirecting the client to for cppm does not match the certificate for the site the client is requesting  (https://www.yahoo.com does not match https://cppm).  You can test this by having the client initally request a non-https site.  Sites like Yahoo and Google that are 100% https present this issue.

 

I am not sure there is a solution to this.  Please let me know if you get the same issue when you have the client initially request a non-https site...

wireless_network10, you are running into the HSTS issue, https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
your clients must try a non-https request to get the captive portal.
Unless you begin whitelisting certain domains which is a workaround.

We are going through the same thing

[EDIT] sorry for the hijack of the the thread.

 

pmonardo could you explain how HSTS plays into this? as far as i know it forces you to access a site on HTTPS. but with a "hijack" that is used with a captive portal i believe you will run into issue also if HSTS isn't used.

Is this still the way it is, as weve just started piloting our Captive Portal.. and are getting reports that it doesnt work, as most peoples browsers are trying to connect to https://www.google.com and see the "Your conneciton is not Private"" error. 

 

Yes, if they do go to a non https site, the CP login page kicks in.. but shouldnt the hijack and redirect happen regardless of the url they are trying to connect to? 

 

We are a  large site, and trying to tell users that they have to go to a non https site (when most probably wouldnt really understand this) would be an impossible task.  People just discover there is a Guest network available, select it, then read the T&Cs and register... but they dont get any of this where a https page is trying to be fetched, so simply think its broke!

 

 

 

This is normal as Google is requesting a certificate which you cannot provide. Expected behavior and your users will need to go through an http site unfortunately. We are dealing with similar issues and can "hack" our way around it by whitelisting, etc..but not the best way to do it...

Read up on HSTS

I'm on mobile so I can't give more info right now...


Pasquale Monardo
Conseiller Principal Solution R?seaux, Op?ration | Senior Network Solutions Consultant, Operation

T 514 385-4448 #204 DATAVALET.COM

5275, chemin Queen-Mary, Montr?al (Qu?bec) H3W 1Y3 Canada

CE COURRIEL AINSI QUE CES DOCUMENTS JOINTS peuvent contenir des renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire d?sign?, veuillez nous en informer imm?diatement et effacer toute copie. Merci. THIS EMAIL AND THE DOCUMENTS ATTACHED may contain privileged or confidential information. If the reader of this message is not the intended recipient, please notify the sender immediately and delete the original message. Thank you.

Will have a read up, I had seen it mentioned above...

 

Still, would help if the portal page was still served as we could then provide information to Users on how to workaround the problem!  I just thgouth that the Captive Portal page would jump up on the request of any URL....

 

Im not quite sure how we go telling potentially 100's if not 1000's of users every day, that they have to browse to a non http website, let alone, explaing to them whats happening  -  put posters up!?

The other option is to not use https if you're not asking your guest users for sensitive information.


Thanks,
Tim

So if the Captive Portal page was http, the hijack would work regardless of whether or not the browser was intially trying to fetch a https page, i.e., google.com?

 

We are only requiring basic contact info, name, tel and email.. which could actually be anything, as we arent validating anything.. so could be http....

Even if it is HTTP and the user tries www.google.com first, they will get a certificate error as you are attempting to redirect them to a captive portal when in fact they are expecting the Google certificate.

Did you disable require https in ClearPass?


Thanks,
Tim