Wireless Access

So, I recently set up a captive portal according to the docs, using a public certifcate. For the web-UI of the controller itself we're using a different certificate.

As expected, this works.

However, after a successful login, the captive portal server presents the wrong certificate to the client (for example. for the logout popup).

I have the cplogout policy in place, and the logout works as expected. However, once a user is logged in, the captive portal server presents the controller's web-UI certificate, not the captive portal certificate, which means the user gets a DN mismatch error.

So, without using a wildcard certificate, how can I make sure a user gets the correct cert for captiveportal-login.xxx.com for the logout popup, and not the controller's web-ui cert?

Right now we are using the internal captive portal. Once everything works with our initial wifi deployment we plan on switching to clearpass. 

We are running 7030 Mobility Controllers with ArubaOS 6.5.1.4, btw.

just to further clarify things, our setup is like this:

• aruba-vc.ourdomain.com with a non-wildcard certificate for the web-ui.
• captiveportal-login.ourdomain.com with a non-wildcard certificate for the captive portal server.

when somebody browses a site like google.com, the DNS request is intercepted and resolved to the captive portal server's IP (which is also the default GW for that subnet), and thus the https request gets redirected to https://captiveportal-login.ourdomain.com/..., with the right certificate. So far, so good.

Once the logon is complete, the logout popup opens, with an URL of https://captiveportal-login.ourdomain.com/..., but the wrong certificate from aruba-vc.ourdomain.com, thus triggering a SSL certificate name mismatch error.

That could be a bug.  Quite frankly, most browsers today have a popup blocker, so most people don't even enable the logout feature, because the popup blocker typically blocks it.  I would open a TAC case...

@colin, 

we'll also deactivate the logout popup once the deployment is done, but for testing purposes it's quite handy to be able to log out again.

That is a perfectly legitimate reason.

My point is it is probably a bug, but not seen in the wild and not fixed, because it gets blocked all of the time.

@colin,

thanks for your feedback. as per your suggestion, I've opened a TAC case. 

How you did the request for that certificate?

I had a similar problem, when i was using a public certificate.  I had that problem happening for some reason when i did the CSR with the controller and sign it with digicert...

At the end i was able to resolve it doing the CSR from a demo clearpass we had. i signed that with digicert.  I downloaded a .pem containing all certs(trusted root, CA, And the certsigned itfselft) and i added manually the private key on top of that).  I uploaded that to the controller and i never got that error again, and everythign worked like it should.

The different in my case was that i was getting a error on the certificate i should not get becuase i was using apublic certifiate but the error was the same, certificate name missmatch, i was getting that in the portal  not after authenticating.

Cheers

Carlos

not that it matters for this problem, but we never use the built-in CSR function, because we have the requirement to archive the private key.

so what we do is we manually create the CSR using OpenSSL, then merge the entire cert chain + the private key into a pfx and import that.

again, the certificates are not the problem. the problem is that the wrong certificate gets presented to the client.