Chris's Wiki :: blog/linux/NetworkManagerTLSFor8021x

Getting NetworkManager to probably verify TLS certificates for 802.1x networks

August 2, 2019

I'll start with my tweets:

We have an 802.1.X WPA2 Enterprise university-wide wireless network, using PEAPv0 authentication, which involves a TLS certificate. I do not appear to be able to get NetworkManager to verify the TLS certificate in a way that will let me actually connect.

The only way I can connect to our university wifi is by setting 'No CA certificate is required'. I cannot supply a CA certificate that works (I've tried), and I cannot turn on 802-1x.system-ca-certs ; nmcli just doesn't save it, no matter what, without any reported error.

With the aid of some replies from @grawity, I was able to navigate to a solution that allows me to connect without that 'No CA certificate is required' having to be set, and probably even verifies the TLS certificate.

The magic trick for me was telling NetworkManager that it should use the system bundle of TLS certificate as the 'CA certificate' it wants. The one important trick is that NetworkManager wants the PEM format certificate bundle (and/or certificate), not the DER form. How you tell them apart is that the PEM form is base64 ASCII while the DER form is binary. Anything with a .pem extension had better be a PEM file, but a .crt extension can be either.

On Fedora 29, the system certificate bundle is found as either /etc/ssl/certs/ca-bundle.crt or /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem; the former is a symlink to the latter. On Ubuntu and Debian, you want /etc/ssl/certs/ca-certificates.crt. I don't know if there are any special SELinux considerations that apply depending on the path you select, because I turned that off long ago on my laptop.

I don't know if this setup makes NetworkManager actually verify the TLS certificates (or perhaps wpa_supplicant, which is apparently the thing that really does the work even when NetworkManager is being the frontend). But at least I'm not telling NetworkManager to maybe ignore TLS security entirely.

(When I was looking at logs through journalctl, they were sufficiently ambiguous to me that I couldn't be sure.)

Sidebar: A further puzzle

At this point I don't have my laptop and its logs of TLS certificate information handy, but the more I look at our university page for campus wireless and the certificates it lists, the more puzzled I get. My attempts to verify the TLS certificate started with the TLS certificate listed there and proceeded through what 'certigo dump' told me were the CA certificates for that TLS certificate. However, now that I look more carefully, the page also has a CA bundle that is supposed to be current, but that CA bundle has a rather different set of CA certificates. It's possible that had I gotten and used that CA bundle, the actual 802.1x TLS certificate I was presented with would have verified.

(It's apparently possible to capture the 802.1x server TLS certificate, but it may not be easy. And you have to be on the wireless network in question, which I'm not as I write this entry.)

Comments on this page:

From 193.219.181.226 at 2019-08-02 05:57:57:

I don't know if this setup makes NetworkManager actually verify the TLS certificates (or perhaps wpa_supplicant, which is apparently the thing that really does the work even when NetworkManager is being the frontend).

Yes, all those 802-1x options are passed pretty much raw to wpa_supplicant and all of EAP is handled there. (As long as NM logs Config: added 'ca_path' value..., it should be received by wpa_supplicant.)

Probably an easy way to check whether the CA cert parameter works would be to deliberately configure a wrong CA and expect verification to fail.

But at least I'm not telling NetworkManager to maybe ignore TLS security entirely.

When using system CAs, hopefully you also have 802-1x.domain-suffix-match set as well? Without it, there's still practically no protection from fake APs as anyone could buy a cert for any domain from the same CA.

It's apparently possible to capture the 802.1x server TLS certificate, but it may not be easy. And you have to be on the wireless network in question, which I'm not as I write this entry.

If you happen to have direct access to the RADIUS servers, then you can use eapol_test (bundled with wpa_supplicant); it has an option to perform the same handshake directly and dump the certificate chain to stdout.

(Also, chances are the same certificate is used for both "UofT" and Eduroam networks – the latter appears to use COMODO_RSA_Certification_Authority.pem when testing with foo@utoronto.ca.)

By Alan J. Wylie at 2019-08-02 08:53:56:

I had a recent issue with TLS and 802-1x, no idea whether it's related, however.

I used to use WiFi, but now have a wired connection for my work laptop.

I went into the NetworkManager GUI and set it not to connect to WiFi automatically.

Some time later I went into a meeting and discovered it wouldn't connect.

It turns out that TLS1.2 needed to be disabled.

The setting is documented at https://developer.gnome.org/libnm/stable/NMSetting8021x.html#NMSetting8021x--phase1-auth-flags

The problem is that the small print in the NM GUI says "Warning: the connection contains some properties not supported by the editor. They will be cleared upon save" and my editing of the connection had lost this setting.

Written on 02 August 2019.

«	How not to set up your DNS (part 24)

If you can, you should use flock(1) for shell script locking »