Controller Based WLANs

How does Aruba Controller work with wild card certificate for captive portal authentication?

by on ‎09-19-2014 05:41 AM

Answer :

 

An Aruba mobility controller ships with a default SSL certificate with the Comman Name(CN): securelogin.arubanetworks.com. The behavior of the controller is to adopt the name defined in the CN of the certificate as its virtual name. This means that any time a wireless client connected to the captive portal ssid, it attempts to resolve the name securelogin.arubanetworks.com, the controller will always return its switch IP by default.

When using a 3rd party wildcard SSL certificate is used for captive portal, the CN on that certificate will be used to redirect to the captive portal page. For example, if the SSL certificate has the CN: wifi.example.com, then wifi.example.com will always resolve to the switch IP of the controller.

For the captive-portal redirection, the certificate mapped for captive portal should have FQDN as the CN in the cerificate. In case of wildcard cerificate, an asterisk is used to signify that any host name can be used with that certificate. When a wildcard SSL certificate is installed on the mobility controller for captive portal, it replaces the asterisk with the host name "captiveportal-login". In our example, the virtual name will be "captiveportal-login.example.com"

rtaImage.jpg


In the packet capture, the controller replies saying that it has “temporarily moved” to <https://captiveportal-login.arubanetworks.com/[string that identifies client]>. 

Comments
pete_elms

hi Anandkumar,

read you article above. Quick question.

what is the process for getting the wildcard cert onto the controller?

cheers

pete

 

rajo7

Hello,

In ClearPass Guest, what should we use as hostname in the NAS vendor settings when using wildcard cert?
Is it captiveportal-login.example.com?

Thanks

Guru Elite Guru Elite
Yes, please see here:
http://community.arubanetworks.com/t5/Controller-Based-WLANs/ArubaOS-Default
-Certificate-Revocation-FAQ-Controllers/ta-p/275809
sd48tech

I have uploaded our wildcard cert to the controller and it is working. I am curious though why the cert still needs to be accepted by the client when the captive portal address is https://captiveportal-login.mydomain.com and the cert is for *.mydomain.com

 

Thanks

Chris

Guru Elite Guru Elite
Not sure what you're asking. Are you receiving errors?
sd48tech

Instructions for generating self signed cert using openssl states:

 

"Note: Using a self signed certificate for captive portal authentication can cause browsers to display a certificate warning. Hence it is recommended to have a publicly signed certificate for captive portal authentication. If there are multiple controllers, we can either install a single publicly signed certificate on all the controllers or go for a wild card certificate"

 

I have used my wildcard certifificate and browsers still display the certificate warning.

 

Chris

Guru Elite Guru Elite
Publicly signed certificates should be used for captive portal, not self-signed.
sd48tech

Yes... I have used my publicly signed GoDaddy wildcard certificate... and still recieve the certificate warning.

Guru Elite Guru Elite
Are you seeing it during initial redirection or during the credential submission?
sd48tech

During the initial redirection.

 

Thanks

p3rl

  I believe how this works is  : 

 

One is not able to avoid the cert warning before initial redirection, in cases, when after connecting to ssid, the redirection to CP page don't happen in background and one need to manually open the browser and put some site address.
In the browser you must have entered  a https site. 

(like https://google.com).

 Your browser expect to see a cert signed to CN= GOOGLE.COM 

 However, in the background we are doing redirection and the ssl communication happens with controller and not google.com. 

(Contrary to what our browser expects)

 Since the browser will  get cert from controller signed to CN : SOMETHING.YOURORG.COM  but never to Google.com, so it will always be untrusted and hence  you are provided the security exception. 

 

If this is the case, this behavior cannot be changed. 

 

The only workaround for this is  to go to  a http site initially after connecting to ssid and not https. 

_________________________________________________________________________________

____Unnecessary details below : _________________________________________________________

 

After connecting to ssid :  

If http connection started with any website, a http connection start between end device and controller
else
if HTTPS connection started with any website, a HTTPS connection start between end device and controller

(At this stage controller will send its cert to end device, while end device expect to see cert of site browsed initially,
and hence there will ALWAYS be a cert error, whenever HTTPS is chosen as choice of communication. )
The only solution would be to make sure initial url tried on browser  is for a http website. 

The second case when we dont get the warning would be, if a ssl session is actually started with and the cert  signed  to google.com. Don't know how redirection will work in that case and if it is a possibility. I believe not. 



2) Second time during the Captive portal work-flow, a ssl session terminates on CPPM. This is before we get the self-registration/weblogin form

 

This again depends on the following settings :

If in authentication we have chosen http connection :

end device ---------- http connection ----------- CPPM.

else

if in authentication setting on cppm & controller we amke it https

end device---------ssl communication -------- CPPM.

(In this case CPPM https cert will be send to end device and if is not signed by Public CA, we get cert warning,.
IF WE INSTALL A PUBLIC CA SIGNED HTTPS CERT ON CPPM, NO WARNING SEEN)

3) The third ssl communication again happen with controller.  This is after we click on login button, post-registration.

This again depends on NAS vendor setting :

SECURE LOGIN_HTTP_HTTPS.png


If ( Guest > self-reg page > edit > NAS vendor setting > Securelogin : Secure login using https)
END DEVICE--------- SSL/HTTPS ------- CONTROLLER ========RADIUS ====== CPPM

Else if
Secure login = Send cleartext password over http, a http connection start between end device and controller
END DEVICE--------- HTTP ------- CONTROLLER ========RADIUS ====== CPPM

(Here again we will get security exception if controller cert is not signed by public CA.
but if we have public ca signed cert, no warning seen. )

So the phrase that suggest that using public-signed cert we can avoid cert warning, it is for the last two scenarios.  

This is how i believe (through much observation and testing) this works. 

I would really appreciate if someone can further verify this.  

sd48tech

That makes sense to me and I can accept that as default behaviour at redirect. In my testing I get the same behaviour from an OpenSSL cert as I do from my publicy signed wildcard cert, so for practical puroses I don't see any benefit to using the wildcard with the Captive Portal as suggested in the below quote. If there is another cert warning referenced in the below advice, I don't see it and thus see no need to use the wild card cert...

"Note: Using a self signed certificate for captive portal authentication can cause browsers to display a certificate warning. Hence it is recommended to have a publicly signed certificate for captive portal authentication. If there are multiple controllers, we can either install a single publicly signed certificate on all the controllers or go for a wild card certificate"

 

No need to reply... the above quote just led me to believe that the certificate prompt at redirect might be avoided with the use of a publicly signed wild card cert... It's not the case and I can happily move on with what we have.

 

Thanks all for the input and responses.

 

Chris

 

 

 

 

 

Search Airheads
Showing results for 
Search instead for 
Did you mean: 
Is this a frequent problem?

Request an official Aruba knowledge base article to be written by our experts.