Background: An Aruba mobility controller ships with a default SSL certificate with the 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 controller attempts to resolve the name securelogin.arubanetworks.com, the controller will always return its switch IP by default. When using a 3rd party SSL certificate, the CN on that certificate will be adopted as its virtual name. 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. Problem: A wildcard SSL certificate does not have a host portion of the CN defined. Instead, an asterisk is used to signify that any host name can be used with that certificate. In this case, the controller cannot use *.example.com as a virtual name since that is not a valid FQDN. Solution: When a wildcard SSL certificate is installed on the mobility controller, it replaces the asterisk with the host name "captiveportal-login". In our example, the virtual name will be "captiveportal-login.example.com" When defining a web login page in ClearPass Guest, the "address" field defines this virtual name of the controller where the captive portal client will post its credentials after completing the web login form. You must use "captiveportal-login.example.com" here, replacing the example portion with your domain portion of the wildcard SSL certificate.
© Copyright 2024 Hewlett Packard Enterprise Development LPAll Rights Reserved.