hi medievaldes
This is a pretty common complaint these days, especially if this is an older (i.e. non 72xx) controller. As more and more apps and people move to https as a default method of accessing the web, the load caused by cert processing on the controller has gone up and up.
Most of the time, if there are open SSIDs and CP with https enabled, then the clients that are associated (especially with smart phones) are banging away on all sorts of https URLs, such as facebook, twitter, akamai, amazonAWS, playstore, apple etc.
A given client sitting in the initial-role (with CP) with no intent of logging into the captive portal is still generating these https requests periodically. Each of these will put load on the controller as it intercepts the https and sends the 302 redirect for the captive portal.
There are a few options, I will outline them here in terms of increasing complexity but better return on CPU. If you need assistance with these, TAC can help.
1> switch to http captive portal with https submit
Change the form in the CP source to be https:// action. This will prevent every single session from causing https cert processing load until the user actually attempts to log into the captive portal. In some cases this will be sufficient, if it's a full on public hotspot, it may not be. The users credentials are still protected since the form action is https.
If you are using the Aruba internal CP and a custom login page, take a flash backup and then edit the "login" page file (it will be in upload\custom\<name of cp profile\) in a text editor. Find the login form, it looks like this:
<form action="/auth/index.html/u" method="post">
<input type="hidden" name="user" id="user" type="text" value="user1" class="text" accesskey="u" />
<input type="hidden" id="password" name="password" type="text" value="passwd1" class="text" accesskey="p" />
<input type="hidden" name="cmd" value="authenticate" />
<button type="submit">I Agree to this Terms and Conditions</button>
</form>
then modify the "action" within the form to be as follows:
<form action="https://securelogin.arubanetworks.com/auth/index.html/u" method="post">
save the file and re-upload to the controller as a custom login page. If you renamed it, dont forget to edit the CP profile login URL. Note that the above assumes the Aruba default cert with CN="securelogin.arubanetworks.com" is still present, if you are using your own cert, then modify as required.
Finally, go to the captive portal profile and tick the "Use HTTP for authentication" checkbox.
2> disable https redirection
This is a bit of a big hammer approach, but will solve the problem instantly. Perform this in conjunction with 1> above, and it essentially means to modify the https redirection rule in the captiveportal ACL to deny rather than dst-nat 8081 the https traffic. The caveat with this approach is that any user that is trying to pop the captive portal with some https:// home page, will get an error until they attempt to launch some http:// based website.
3> same as 2> but with whitelisted sites
If there are some wellknown https:// based sites, you can try introducing a named netdestination that allows some of these through, thus allowing the captiveportal to pop up for something like https://www.facebook.com.
This can be achieved by creating a netdestination called something like allowed_https and populate it with things like name www.facebook.com or name *.yahoo.com as examples. Then we need to modify the "denied" https rule from 2> above to be "user alias alllowed_https svc-https dst-nat 8081 position 3".
Note that you have to be careful with approach 3> not to add too much back in, else you are just back to the same problem.
hope that helps,
-jeff