Just a heads up that next month sometime, a security researcher plans to publish the fact that he was able to extract the private key for the default "securelogin.arubanetworks.com" certificate from an ArubaOS image. This is something we've always cautioned against (see for example http://community.arubanetworks.com/aruba/attachments/aruba/115/3996/1/customer-advisory-expiring-ssl-cert.pdf from a few years ago) but as many times as we say it, people either ignore it or don't understand it.
To cut to the tl;dr version: If you are relying on the factory-default certificate to protect HTTPS communication with an Aruba product, this certificate is providing you with very little security because with the private key, an attacker can conduct a man-in-the-middle attack without you knowing it. What can you do? Buy a certificate from a public CA. If you don't want to spend a lot of money, I recommend https://www.ssls.com/.
In the future, expect to see 'securelogin.arubanetworks.com" disappear from the product, to be replaced by a self-generated, self-signed certificate. In the past we were persuaded by the "but certificates are too complicated - just leave the factory default cert as-is and customers who care about security can update it" argument, but I now think we're doing a disservice to customers by giving them too much rope with which to hang themselves. I'm happy to hear arguments to the contrary, but I'm going to be pushing to torpedo this thing.
Any questions or concerns, please let me know!
Jon - Will it also be removed from Instant and MAS around the same time?
Jon - Will it also be removed from Instant and MAS around the same time?
That would be the goal, yes.
Totally agree with your advise. During deployments we will always try to persuade the customer to buy two SSL certificates. One certificate for the controllers, the other one for the ClearPass machines.
Extraction of the SSL certificate from the Aruba Instant image is also possible. Contact me if you require any details.
Took a bit longer than I expected, but this is what I was expecting to be published back in June or July:
Thanks for the heads-up. Also thanks for re-thinking the certificate.
Certs can be confusing, but they're not all that hard once you have to learn how they work and interrelate. Dropping the pre-signed cert for a self-signed one is a great step.
Any thoughts on letting iAP and Controllers get certs from Airwave or Clearpass?
You're right Pasquale. Thanks for the link.
I was meaning more like a cert-request/CA relationship - I would feel better if each cluster had a unique certificate for the management page, I can see a universal certificate for the captive-portal though.
Bumping up this thread again, because the same group of researchers has recently re-published and expanded their work.
ArubaOS 8.0, by the way, generates a self-signed certificate for administrative access. Each controller will thus use a unique self-signed certificate. Those who want to keep using that can feel free to individually trust each of those self-signed certs. Those who like using PKI should be installing their own certificates.
Also, note that Aruba Instant contains a factory default certificate as well, which has the CN of "instant.arubanetworks.com". Same story - you shouldn't be using this certificate in a production network. This one, at least, is a self-signed certificate so hopefully nobody ever got the idea that it was providing any security. But every Instant AP includes the same self-signed certificate, so unlike what you can do with ArubaOS 8.0, you definitely cannot trust this certificate.
I had not seen this news and our controller (Aruba OS 22.214.171.124) was still using the default certificate. Now that certificate seems to suddenly have been revoked since today or so? Causing a lot of trouble now. (can't download VIA profile any longer? All VIA-clients always seem to think they're on a un-trusted network, even though it's on a trusted network?) How can I fix this the quickest? Do I need to purchase a certificate etc.?
Apparently a non-valid certificate for the domain name was okay for things to work normally, but a revoked certificate is not okay? Does that mean re-uploading a new non-valid certificate should make things work? Of course, it's better to upload a valid certificate I guess. But just wondering.
Also, I'm wondering if RAPs will continue to be able to connect. So far so good....
Now you paid for a cert - next you need to actually obtain it.
If browsers still complain about your new cert not being trusted, and you think you did everything correctly, the most likely problem is the certificate chain. You need to combine the server certificate AND the intermediate CA certificates (all of this will be emailed to you) into a single file, which you upload to the controller.
All told - this is too complicated, and requires you to know too much about certificates, cert chains, certificate file types, etc. It's the result of letting security engineers design this part of the software. I've made some suggestions internally for how to make this easier.
If all of this sounds like too much of a pain, go to https://msol.io/blog/tech/create-a-self-signed-ssl-certificate-with-openssl/ (or even http://www.selfsignedcertificate.com/, though I haven't tried this myself) and create yourself a self-signed certificate. Upload it to the controller. The first time you use it, tell your browser to show you the certificate, and "install" it - you're telling your browser to remember this certificate so that the next time you use it, it will be trusted. It's not the best security approach, but it will get the job done.
@eriknl2 wrote:Thanks. I think I might also have to change Management/General and then WebUI Management Authentication Method/Server Certificate ?
Yes. Sorry I forgot to mention that.
If you're using captive portal, you'll also want to change it there.
Had the same issue, revoked cert, VIA client couldn't download profiles. Swapped the revoked cert with our own trusted cert for the vpn. Issue we're having now is that I assume the same revoked cert was also used on the APs, AirWave, Controller because we can no longer access those sites. We don't even get an invalid cert prompt in the browser, it is just inaccessible.
Everyone, it was found that the current certificate in ArubaOS and Aruba Instant (serial number 01 da 52) has been revoked by the Certificate Authority.
Unfortunately, that means that unless you followed the advice up this thread and in the bulletins, and moved to your own SSL certificate, you may be in a situation where you cannot connect to your controller anymore.
Google Chrome is supposed not to do CRL checking, so using another browser may fix the issue. I signaled internally in Aruba the revocation, so probably things will start happening now.
In the meantime: change your controller and IAP certificates as soon as possible and use your own certificates as you web browser may keep you out of your controller or IAP.
How can I change my controller certificates if I can't access my controller?
Probably the easiest way is to use a browser that doesn't check revocation or where you can override the CRL check.
You can also import the certificate through the CLI: http://www.arubanetworks.com/techdocs/ArubaOS_64_Web_Help/Content/ArubaFrameStyles/Management_Utilities/Managing_Certificates.htm , and then configure it like:
Also contact your Aruba partners or Aruba TAC if you have issues.
In the case you cannot get a public certificate on short term, or just use the web-based management on the controller, TAC has released the following article on how to generate a self-signed certificate: http://community.arubanetworks.com/t5/Controller-Based-WLANs/Generate-self-signed-certificate-with-OpenSSL/ta-p/275357
If you have an Airwave server, you can use that one to run the OpenSSL commands; most Linux based servers have OpenSSL installed by default as well.
If you use captive portal authentication (either internal, or external captive portals like ClearPass), you probably want to get a public HTTPS certificate for your controllers.
Please contact your Aruba partner or Aruba TAC if you need advice.
© Copyright 2023 Hewlett Packard Enterprise Development LPAll Rights Reserved.