Security

Hi All,

Might be showing some ignorance here, and I suspect somebody knows a quick answer!!!

When using Clearpass, in the scenario where a user registers successfully, then clicks the “login” button on the Clearpass page, this invokes a second HTTPS redirect to the controller (Aruba), which generates a RADIUS request out of the controller to the Clearpass ultimately switching the user role (to a logged in flavour). I am paraphrasing a bit, but I understand this part of the engine I think.

My questions is regarding the HTTPS part of this in terms of certificate considerations. Take an Apple device as an example (where Safari is getting more and more difficult in terms of security). Initially, the client is looking at the Clearpass server (assume there’s a valid cert on it which is ok). When the click “login”, they redirect again to the controller to “poke” it, and this redirect is formed using the controller’s loopback or NAS IP (derived by the Clearpass server). Assume again that the controller has a cert, and that it’s CN and other fields are “controller1.customer.com”. I’m wondering if an Apple browser is going to accept the controller cert, considering that the URL in the redirect is formed using the controller’s IP, rather than the FQDN in the cert CN field.

Does anybody know if this works without issue, or whether some client browsers consider this an insecure site as a result of the IP in the URL (specifically Apple most likely!)?

As far as I'm concerned you can specify in the Clearpass to use either IP address or FQDN to connect back to the controller and the process will use this one. By default it is set to securelogin.arubanetworks.com in case of an Aruba controller.

And there is another thing you should consider which is OCSP. In a typical captive portal installation the initial role is very limited so the client will not be able to communicate on the Internet so you need to make sure you allow the IP addresses for online certificate verification. If the two certificate is issued by different CA's then you need to allow the client to communicate with both CA's OCSP servers. This can be a problem since the IP addresses tend to change from time to time (unfortunately you can't use FQDN in firewall policies on Aruba controller).

I might have a look into the FQDNs in the Clearpass instead of the IPs then. Point taken, and thanks.

Regarding the OCSP, I've actually already got that part in place by leveraging the walled-garden feature. If you use that, you can specify a DNS whitelist to resolve OCSP servers instead of by way of IPs. Much better. Maybe look into it for yourself?

---

@The.racking.monkey wrote:

I might have a look into the FQDNs in the Clearpass instead of the IPs then. Point taken, and thanks.

 

Regarding the OCSP, I've actually already got that part in place by leveraging the walled-garden feature. If you use that, you can specify a DNS whitelist to resolve OCSP servers instead of by way of IPs. Much better. Maybe look into it for yourself?

---

Good point on walled-garden. It seems to be a good idea to let the client verify the certificate via OCSP. Thanks.

I personally always use the default securelogin.arubanetworks.com with the factory cert and if the OCSP is allowed in the policies then it works with all kind of clients and browser (hadn't ran any issues yet).

In my setup, I installed a CA Certificate on the controller for securewireless.ourdomain.edu and another CA certificate, our domain wildcard cert, on Clearpass Guest.  

On Clearpass, I refer to the controller by IP Address as you described.  During the redirect back to the controller after authentication, it calls the domainname that my certificate is registered for, securewireless.ourdomain.edu.  

I have had no issues with certificate errors on any device, IOS included, save for one small one that I am about to open a TAC ticket for.  On an iPhone4s and an iPad 3 running IOS 6.0.1 specifically, using the Chrome Browser only, i get an error that states roughly "This sites certificate reports as securewireless.ourdomain.edu but is reporting its actual name as securelogin.arubanetworks.com do you wish to proceed?"  Once they login, the redirect then fails, however, they are actually authenticated and can go on to anywhere.  

That is the only issues I have had so far and they seem isolated to the Chrome Browser on spectific devices with iOS 6.0.1 in our environment.  All other browsers I have tested on the various OS's seem to work without problems when the IP is referenced on Clearpass and the CA Cert is referred to as something else on the controller.

Anyone else seen these issues?

Thanks for the input. Will look into it a bit further myself!