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"In the packet capture, the controller replies saying that it has “temporarily moved” to <https://captiveportal-login.arubanetworks.com/[string that identifies client]>.
As mentioned in the FAQ, wildcard support was added to Instant in 4.3
Yes, we're running instant, our I-APs are on firmware version 188.8.131.52-184.108.40.206_56707.
thank you for your quick response - i changed the two fields shown in the screenshots in this article:
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?
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?
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.
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.
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 controllerEND 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.
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:
I have used my wildcard certifificate and browsers still display the certificate warning.
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
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
read you article above. Quick question.
what is the process for getting the wildcard cert onto the controller?
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.