Controller Based WLANs

Why does it sometimes take 10-15 seconds to load the captive portal page when using Firefox?

Aruba Employee

This article applies to all Aruba controllers and ArubaOS versions.

 

Symptoms : Captive Portal Page takes some time to load.

 

 

Aruba captive portal 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.
     
So almost all popular web browsers now support certificate revocation checking.

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.
 
Solution :
 
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 check 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 with the respective IP address for that particular distribution point.
NOTE: There may be multiple CRL distribution points for a Certificate. In that case will need to allow all those IP addresses.

3) Configure a new netdestination in the Aruba controller like this: 


Configuration terminal
netdestination godaddy
host <CRL IP address obtained in step 2>

4) Configure a new ACL like this: 

Configure terminal
ip access-list session <acl-name>
user alias <alias-name> svc-http permit   //Alias-name is the netdestination that was created in step 3.

5) Apply this new ACL to the initial role in the AAA Profile. Make sure this new ACL is above the captive portal ACL in the initial role.

This workaround should allow users to do the CRL checking and expedite the captive portal service
 
Version history
Revision #:
1 of 1
Last update:
‎07-02-2014 02:08 PM
Updated by:
 
Labels (1)
Contributors
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: 
Is this a frequent problem?

Request an official Aruba knowledge base article to be written by our experts.