Controller Based WLANs

As mentioned in the FAQ, wildcard support was added to Instant in 4.3

https://community.arubanetworks.com/t5/Controller-less-WLANs/ArubaOS-Default-Certificate-Revocation-FAQ-Instant/ta-p/275814

Yes, we're running instant, our I-APs are on firmware version 6.4.4.8-4.2.4.3_56707.

Hi Tim,

thank you for your quick response - i changed the two fields shown in the screenshots in this article:

https://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/Weblogin-NAS-Address-configuration-options-in-multi-controller/ta-p/275426

and uploaded our wildcard certificate to the virtual controller as capitve portal certificate. When logging in to the guest wifi network the name captiveportal-login.example.com  can't be resolved (of course i did not use .example.com, but the name behind the asterisk in our certificate). Did i miss some setting which needs to be changed?

kind regards,

Christoph

We're trying to change our configuration so it does not use "securelogin.arubanetworks.com" anymore. What i did not understand in the directions above: Do we have to create the name "captiveportal-login.example.com" in our DNS and should it point to the ip of the controller? The name "securelogin.arubanetworks.com" does not exist in any DNS, will the controller create the name "captiveportal-login.example.com" on demand so that it point to its own ip?

kind regards,

Christoph

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

  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 :

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.  

During the initial redirection.

Thanks

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

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

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

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

hi Anandkumar,

read you article above. Quick question.

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

cheers

pete