Wireless Access

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?

---

@cappalli wrote:

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:

http://blog.sec-consult.com/2015/11/house-of-keys-industry-wide-https.html?m=1

 

 

Thanks Jon.

Any idea when this will be removed from AOS, Instant and MAS?

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?

IAPs can be pushed from Airwave. I had the same question
http://community.arubanetworks.com/t5/Aruba-Instant-Cloud-Wi-Fi/IAP-certificate-s-per-VC-or-pushed-from-Airwave/m-p/238690#M10583

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 6.3.1.22) 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....

You would get a basic SSL web server certificate for your controllers.



Also, this would not affect RAPs.

1. Visit https://www.ssls.com/
2. Scroll down to "PositiveSSL" (the one that says $4.99/year)
3. Click the shopping cart button.
4. Pay some money

 

Now you paid for a cert - next you need to actually obtain it.

 

1. If you have just one controller, open the WebUI, go to Configuration->Certificates->CSR.  Set the key length to 2048.  Put your controller's hostname into the Common Name field.  Fill out the rest of the information.  Click "Generate New".  Click "View Current".  Copy and paste this into the www.ssls.com page where it asks you for your CSR.  Skip to step 3.
2. If you have multiple controllers and want to use the same certificate on all of them (note:  not recommended from a best security practice standpoint), you can't use the ArubaOS CSR-generation routine described in step 1, because you won't (easily) get your private key back.  For this, you need a computer with OpenSSL on it.  There are a number of tutorials online that tell you how to generate keypairs and CSRs using OpenSSL - follow one of them.  Once you get a CSR, paste it into the www.ssls.com page where it asks for your CSR.  
3. Go through the verification process.  
4. Obtain cert in email.
5. If you generated your CSR on the controller (step 1), upload the certificate back to the WebUI with Management->Certificates->Upload.  Set the cert type to "Server Certificate".  You are done.
6. If you generated your CSR with OpenSSL (step 2), when you get the certificate, you need to recombine it with the private key that OpenSSL will save to disk, and then that complete package needs to be uploaded to your controllers.  The easiest way is to dump the certificate, the certificate chain (this includes the intermediate CAs), and the private key into a text file.  I am over-simplifying this - but there are many how-tos online.  Make sure you don't leave that text file laying around somewhere that other people can get 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.

Thanks. I think I might also have to change Management/General and then WebUI Management Authentication Method/Server Certificate ?

---

@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?

Jesse,

 

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:

 

web-server profile
   switch-cert "my-certificate-2016"
   captive-portal-cert "my-certificate-2016"

Also contact your Aruba partners or Aruba TAC if you have issues.

 

Firefox still let me into the controller by adding a security exception.

I bought a SSL-certificate at GoDaddy and uploaded it to the controller. I also uploaded the intermediate cert, just to be sure. Also, I set the WebUI cert to the cert I just uploaded.

Aruba VIA seems to be working well again now.

Good thing the RAPs weren't affected. Would have been a big disaster today. Also, I guess we were lucky that VIA connected when it shouldn't instead of not connecting when it should.

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.