I had an inquiry the other day (thanks Peter Neyt) regarding some X.509 certificate changes related to Aruba Activate. These changes should not affect most of our customers, but in case you're using some specific firewall capabilities in your network, you may want to be aware.
In the old days, all Aruba devices making use of Activate would make a connection to "device.arubanetworks.com" using HTTPS. Here's what the server certificate looks like for that endpoint:
Two things to note: the root of the certificate chain is "GeoTrust Global CA", and the expiration date is September 15, 2021. Both of these things lead to a persistent type of problem we've had with devices like switches and APs connecting to a web service. Every few years (now changing to "every year") our server certificate expires and we need to replace it. Normally that would not be a big problem, but three times now in the history of Activate, we've attempted to renew a certificate only to find that the issuing certificate authority no longer existed. In today's case, GeoTrust was purchased by DigiCert and it is no longer possible to obtain certificates issued under the "GeoTrust Global CA" PKI.
Browsers typically don't care about changes in CAs because browsers are updated frequently with new databases of root CAs. If you didn't update your browser for 2+ years, however, you might find more and more HTTPS connections failing because of missing certificate trust relationships. And that's exactly what happens with embedded devices like APs, controllers, and switches that very often run the same firmware for multiple years. We embed root CA lists into the firmware, and the only way to push out a new CA list is to update the firmware (whether or not that's a good design is a different discussion, but that's how it is now..) What this has meant in the past is a forced firmware update, before a certain date, or else the device would stop talking to Activate/Central. This has caused a tremendous amount of pain for both Aruba and our customers.
Going forward (actually, starting a year ago) we're taking a different approach. A little over a year ago we implemented a second endpoint on Activate, called (very creatively) "devices-v2.arubanetworks.com". This is both a change in URL and also an update/modernization in the protocol itself that the devices use to communicate. Here is the server certificate used for HTTPS:
The thing you'll immediately notice is that this comes from a PKI that we own and control. The second thing you'll notice, if you take the time to try connecting to this URL from a standard browser, is that the certificate is not trusted. This is because the root CA of this PKI is a private CA - it's not something published outside of HPE. This is good news because it means we'll no longer suffer from the problem of a CA that disappears and can't renew a certificate. It's potentially bad news because apparently, some customers configure their firewalls to reject HTTPS sessions with sites that have untrusted certificates. If you plug an Aruba AP into such a network, the firewall would block the connection to Activate. The net result is, if you're one of those customers with that type of firewall configuration, you're going to need to either whitelist this certificate/CA, or tell the firewall not to enforce that rule for "devices-v2.arubanetworks.com".
What about browsers? Any server endpoint that is expected to talk with a browser will use certificates issued by a public CA, just as we always have. An example would be "central.arubanetworks.com" or "activate.arubanetworks.com".
A final note - if you're still running firmware from more than a year and a half ago, please look at upgrading. The current certificate is still good for another ten months, but eventually it's going to expire and will not be replaced again.
Any questions?
------------------------------
Jon Green
Aruba Security Guy
------------------------------