12-01-2011 11:46 AM
I am having issues with some MAC's and the captive portal. The computer comes up on the network, but they are not able to pull up the captive portal. Has anyone seen this issue?
12-01-2011 03:42 PM
This is a known issue in Lion 10.7.2.
See this thread for more info (The topic of the thread may sound unrelated but it is relevant... please read the replies of Bruce Stewart in that page):
If you turn off OCSP certificate checks when using a captive portal it will start working. This setting is in the preference window of the Keychain Utility.
Here is more background info and a possible fix in the controller of you don’t want client turning this off.
Online Certificate Status Protocol (OCSP) - is an Internet protocol used for obtaining the revocation status of an X.509 digital certificate. It is described in RFC 2560 and is on the Internet standards track. It was created as an alternative to certificate revocation lists (CRL), specifically addressing certain problems associated with using CRLs in a public key infrastructure (PKI). Messages communicated via OCSP are encoded in ASN.1 and are usually communicated over HTTP. The "request/response" nature of these messages leads to OCSP servers being termed OCSP responders.
Configuring a certification authority (CA) to support OCSP responder services includes the following steps:
- Configure certificate templates and issuance properties for OCSP Response Signing certificates.
- Configure enrollment permissions for any computers that will be hosting Online Responders.
- If this is a Windows Server 2003–based CA, enable the OCSP extension in issued certificates.
- Add the location of the Online Responder or OCSP responder to the authority information access extension on the CA.
- Enable the OCSP Response Signing certificate template for the CA.
The certificate template used to issue an OCSP Response Signing certificate must contain an extension titled "OCSP No Revocation Checking" and the OCSP Signing application policy. Permissions must also be configured to allow the computer that will host the Online Responder to enroll for this certificate.
See this TechNet article for instructions on setting up an OCSP responder under Windows Server. Note that the Enterprise version of Windows Server is required for OCSP responder - the standard version of the server does not have it.
Support for OCSP in the controller was delivered as part of ArubaOS 6.1.
Captive Portal, Firefox, and OCSP
You could be running into an issue where browsers like Firefox attempt to contact an OCSP server, to see if the captive portal certificate is valid and has not been revoked. The OCSP server for that domain is a property of the certificate that you load, and is found in the AIA field of the certificate. Firefox will attempt to contact that server over HTTP or HTTPS to determine if the certificate has been revoked. Because captive portal rules have been configured to capture and redirect HTTP/HTTPS, the check will fail and Firefox will never load the page.
If you turn off OCSP in Firefox (Tools -> Options -> Advanced ->Encryption / Certificates -> Verification) and it works, that means that OCSP is your issue. If you cannot do this for all your clients, you can open up traffic to the OCSP server in your logon role:
For AOS 6.0 and below: Code:
ip access-list session godaddy-crl
user alias godaddy svc-http permit
user alias godaddy svc-https permit
Of course, you would use the ip addresses from the DNS name in the OSCP portion of the certificate. http://www.networkworld.com/details/7174.html
Using AOS 6.1 and later, the Walled Garden feature can accomplish the same thing using DNS names. The following example assumes that the OCSP URL embedded in the certificate is http://ocsp.usertrust.com:
aaa authentication captive-portal default
Another alternative is to not use SSL certificates that contain OCSP URLs. This varies by issuing CAs.
12-02-2011 08:35 AM
Just a side note:
I tried disabling OCSP checking on my MacBook Air at our site, and that did not resolve this issue. I did have to add both the OCSP and CRL address for our certificate provider (Geotrust) to allow OCSP and CRL prior to CP login.
Even if the OCSP disable worked, it would not work on iOS devices, which suffer from the same issue.
12-02-2011 01:35 PM
I have a mac 10.6.8 on my desk and I enabled the checking in firefox and am now seeing the same error that I am getting on the 10.7 clients. I will do some testing and get back to you.
12-12-2011 11:52 AM
Our guest access is open and 10.7.x can never connect using the built in browser. Is this something in the Aruba controller or the client that has to be turned off?
This is the OCSP and CRL issue. You will need to find out the IP addresses of your certificate provider's OCSP and CRL pages. Then you need to add in those addresses as allowed communication in the default CP role (pre CP auth) that you are using.
Just search the forums for OCSP if you need more help on this topic.
12-13-2011 06:06 AM
So for the Guest Wireless, when the login page does pop up, it is HTTP:// and not HTTPS:// ???
If you run the following command, replacing "default" with the name of your CP Profile, you should see the bold line as "Enabled" instead of "Disabled" if you are not using HTTPS:
(Aruba3200) #show aaa authentication captive-portal default
Captive Portal Authentication Profile "default"
Default Role guest
Default Guest Role guest
Server Group default
Redirect Pause 10 sec
User Login Enabled
Guest Login Disabled
Logout popup window Enabled
Use HTTP for authentication Disabled
Logon wait minimum wait 5 sec
Logon wait maximum wait 10 sec
logon wait CPU utilization threshold 60 %
Max Authentication failures 0
Show FQDN Disabled
Use CHAP (non-standard) Disabled
Login page /auth/index.html
Welcome page /auth/welcome.html
Show Welcome Page Yes
Add switch IP address in the redirection URL Disabled
Adding user vlan in redirection URL Disabled
Add a controller interface in the redirection URL N/A
Allow only one active user session Disabled
White List N/A
Black List N/A
Show the acceptable use policy page Disabled
12-20-2011 02:22 PM
We updated from 220.127.116.11 to 6.1.2
For the Captive portal, I whitelisted oscp.comodo.com which is the issuing authority for the default cert. This made it work on the mac's