HPE/Aruba ClearPass 802.1X auth fails with Android 11

Michael McNamara — Sat, 13 Aug 2022 13:34:04 +0000

This is another one of those “it must be the network” posts. It was an interesting problem to chase so I thought it worth the effort to post it here for anyone that hasn’t seen this problem before.

The trouble ticket came in as a brand new “out of the box” Motorola G Pure was failing to authenticate via RADIUS 802.1X to our wireless network using valid credentials. However, if you managed to get it the device connected via guest wireless and enrolled in Soti then it was able to authenticate via RADIUS 802.1X without an issue.

A quick review of the HPE/Aruba ClearPass instance showed an error code 215, a TLS session error. Which interestingly enough was reporting as an expired certificate, although this certificate error was on the client side which was odd giving that historically Android devices don’t validate or care about the RADIUS certificate.

The text of the error read as follows;

EAP-PEAP: fatal alert by client - certificate_expired TLS Handshake failed in SSL_read with error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired eap-tls: Error in establishing TLS session

It turns out I’ve seen this issue before with Android 10 but in that case the device was failing to open a captive portal page when connecting to a guest WiFi network because the SSL certificate securing the captive portal was “invalid” to the mobile. Why you ask? The device had the wrong date/time. And that’s exactly what’s happening here… although Android 11 is taking the issue a little further because it views the RADIUS certificate as invalid it’s not allowing the RADIUS 802.1X authentication to proceed.

The issue is the Motorola G Pure will boot up with a default date and time that appears to be related to date of that specific software build. In this case the default date was June 30, 2022 – fairly new I’d agree. If there is a SIM in the device it will pull the correct date/time from the cellular network, but if these are just being used on WiFi then they won’t automatically update their date/time until they are connected to a wireless network. Unfortunately we had just recently renewed our RADIUS certificate (publicly signed) on July 14, 2022. While the certificate hadn’t expired it wasn’t yet valid because the mobile had a date & time that was before the issue date of the certificate.

This wasn’t an issue in Android 10 because Android 10 didn’t validate the date of the RADIUS certificate, but Android 11 will attempt to validate the RADIUS certificate being used in the RADIUS 802.1X exchange. It should also be mentioned that you’ll need to make sure you have the “Domain” box filled in with the domain of the certificate used by the RADIUS server – that’s new with Android 11 as well.

Cheers!

APC UPS NMC stops responding via HTTPS

Michael McNamara — Sun, 20 Feb 2022 15:22:36 +0000

Who doesn’t love a good mystery, I’m no exception. A few weeks back we had an interesting issue pop-up. It was midnight on a Sunday night and PagerDuty started firing off an alert that a UPS in one of our distribution centers had just stopped responding via HTTPS. The UPS was still online responding to both ICMP and SNMP traffic, so the alert was acknowledged and the alarm was paused until it could be reviewed the next day.

The UPS itself was fairly new having been installed just under a year ago. It was an Schneider Electric/APC 3000RT Smart-UPS with an AP9631 network management card. Interestingly enough we just had an issue with a brand new APC 8000SRT Smart-UPS with an integrated AP9537SUM network management card that had essentially started doing the same exact thing a few days earlier. Only that installation was only a few days old when it stopped working. Again ICMP and SNMP worked fine… as did HTTP (if you enabled it).

What was that all about?

After a few hours of troubleshooting and digging I discovered that the self-signed SSL certificate installed on the NMC had expired. Any attempt to connect to the NMC via HTTPS after that point would result in the socket getting immediately closed upon connecting by the NMC. Removing the self-signed SSL certificate and rebooting the NMC caused the self-signed SSL certificate to be regenerated and the problem was resolved. You can remove the SSL certificate by enabling the HTTP server via either SSH or TELNET (will depend on the age of your card as to which one is enabled by default), login in via HTTP go to Configuration -> Network -> Web -> SSL Certificate and select Remove and Apply. You just need to reboot the NMC and you should be able to connect via HTTPS.

1 Year?

The self-signed SSL certificate is only good for one year, after which you’ll need to regenerate it again. The latest version of the firmware/software (NMC2 – v7.0.4) from APC sets the expiration date for all self-signed SSL certificates out to 2035 – not sure if the web browsers will start to complain about that.

Ripple20?

If you haven’t already patched your APC network management cards it might be a good time to take care of that task as well. We had to patch all of our APC and Eaton network management cards that are used throughout our network.

Cheers!