As part of the login process, Amigopod instructs the client to do an HTTP or HTTPS POST to the controller. The vendor default for Aruba is to use HTTPS which means that the client will attempt to use the controller's captive portal certificate. Additionally, the client will also use Amigopod's certificate if Amigopod is configured to use HTTPS. Most modern browsers can be configured to do OCSP checking. Firefox is one browser that enables OCSP checking by default. For clients in a pre-authentication role without outside access, the OCSP check will fail which breaks the login process. Use the following guide if the Amigopod login works in some browsers but it fails in others such as Firefox.
The Aruba/Amigopod captive portal solution is a Layer 3 authentication mechanism. Captive portal presents user a login page for any website the user is trying to access. Users must pass authentication before they can get full (or configured access level, depends on security policy) access.
To increase security, captive portal (by default) is presented over HTTPS so that user credentials cannot be sniffed. To provide HTTPS service, all Aruba controllers come with a default certificate. However, this certificate is for demo purpose only, and users are strongly recommended to get their own certificate.
This presents an interesting issue when users load their own certificate:
- Starting from Firefox 3, the certificate revocation check is enabled by default.
- Internet Explorer starting with version 7 on Windows Vista (not XP) supports OCSP checking.
- All versions of Firefox support OCSP checking. Firefox 3 enables OCSP checking by default.
- Safari on Mac OS X supports OCSP checking.
- Opera starting with version 8.0 supports OCSP checking.
- Google Chrome supports OCSP checking.
Therefore, almost all popular web browsers now support certificate revocation checking.
Unfortunately, the certificate revocation check runs over HTTP. When the user is presented with the certificate and before the captive portal is loaded, the browser does the certificate revocation list (CRL) checking. Because the check runs over HTTP, it is also intercepted by captive portal. The check fails and, depending on the browser behavior, the captive portal might or might not get loaded. Sometimes it can take more than 10 seconds to load.
To work around this issue, an ACL must be added for the user to access the certificate authority's CRL distribution point. Depending on the CA, the CRL could be different.
To allow CRL to work, follow these steps:
1) Open the certificate and click the Detail tab. Scroll down and find the CRL distribution point. For example, a godaddy certificate could have a CRL distribution point like this: URL=http://crl.godaddy.com/gds1-12.crl
2) Open a DOS prompt and run 'nslookup' followed by the CRL distribution point. For example: "nslookup crl.godaddy.com".
The DNS server should return an entry.
3) Configure a new netdestination in the Aruba controller like this: netdestinaton goddy host a.b.c.d (where a.b.c.d is the result in step 2)
4) Configure a new ACL like this: "user alias goddy http permit"
5) Apply this new ACL to the initial role. Make sure this new ACL is above the captive portal ACL.
This workaround should allow users to do the CRL checking and expedite the captive portal service.
=== Example - securelogin.arubanetworks.com ===
The securelogin.arubanetworks.com hostname is installed by default on all Aruba controllers. It is not suggested to use this in production since this certificate is widely distributed. The certificate is signed by Comodo. In order for captive portal to work with this certificate in Firefox, we need to add the following ACLs in the initial role for the captive portal:
configure terminal
netdestination comodo
host 91.199.212.174
host 91.209.196.4
host 208.116.56.4
host 149.5.128.4
host 91.209.196.5
host 205.234.175.175
host 91.209.196.169
host 91.199.212.169
host 149.5.128.169
host 199.66.201.169
ip access-list session ocsp-acl
user alias comodo svc-http permit
user-role logon //or any role that is the initial role for the captive portal user
session-acl ocsp-acl position 1