FS#30326 - [networkmanager] EAP-TLS does not work

Attached to Project: Arch Linux
Opened by Andrej Podzimek (andrej) - Sunday, 17 June 2012, 07:58 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Tuesday, 29 March 2016, 01:58 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Ionut Biru (wonder)
Jan Alexander Steffens (heftig)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

NetworkManager controlled by kdeplasma-applets-networkmanagement works fine for most networks (802.1x wired, WPA(2)-PSK, WPA(2)-EAP/PEAP/MSCHAPv2). I use >5 of such connections of various kinds and *all* of them work fine.

However, EAP-TLS over WiFi does *not* work. (Never tested this protocol on a wired network.)

Additional info:

* package version(s)

kdeplasma-applets-networkmanagement 1:0.9.0.2-1
network-manager-applet 0.9.4.1-1
networkmanager 0.9.4.0-6
libmm-qt-git 20120617-1
libnm-qt-git 20120617-1
openssl 1.0.1.c-1

* config and/or log files etc.

# Configuration for netcfg that *always* works:
CONNECTION='wireless'
DESCRIPTION='Připojení doma ve Zlíně'
INTERFACE='wlan0'
IPCFG=('link set mtu 2274 dev wlan0') # Workaround for a stupid BUG in dhcpd https://bugs.archlinux.org/task/28832
IP='dhcp'
IP6='dhcp'
ESSID='Net3'
SECURITY='wpa-configsection'
SCAN='YES'
WPA_COUNTRY='CZ'
WPA_DRIVER='nl80211'
CONFIGSECTION='
        ssid="Net3"
        scan_ssid=1
        proto=RSN
        pairwise=CCMP
        group=CCMP
        key_mgmt=WPA-EAP
        eap=TLS
        identity="andrej"
        ca_cert="/var/podzimek-ca/ca-cert.pem"
        client_cert="/etc/network.d/auth/home.crt"
        private_key="/etc/network.d/auth/home.key"'

# This is the common log output in messages.log:
Jun 17 09:40:12 octopus NetworkManager[1618]: <info> Auto-activating connection 'NSU'.
Jun 17 09:40:12 octopus NetworkManager[1618]: <info> Activation (wlan0) starting connection 'NSU'
Jun 17 09:40:12 octopus NetworkManager[1618]: <info> (wlan0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Jun 17 09:40:12 octopus NetworkManager[1618]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Jun 17 09:40:12 octopus NetworkManager[1618]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Jun 17 09:40:12 octopus NetworkManager[1618]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Jun 17 09:40:12 octopus NetworkManager[1618]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Jun 17 09:40:12 octopus NetworkManager[1618]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Jun 17 09:40:12 octopus NetworkManager[1618]: <info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0]
Jun 17 09:40:12 octopus NetworkManager[1618]: <info> Activation (wlan0/wireless): access point 'NSU' has security, but secrets are required.
Jun 17 09:40:12 octopus NetworkManager[1618]: <info> (wlan0): device state change: config -> need-auth (reason 'none') [50 60 0]
Jun 17 09:40:12 octopus NetworkManager[1618]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Jun 17 09:40:12 octopus NetworkManager[1618]: <warn> No agents were available for this request.
Jun 17 09:40:12 octopus NetworkManager[1618]: <info> (wlan0): device state change: need-auth -> failed (reason 'no-secrets') [60 120 7]
Jun 17 09:40:12 octopus NetworkManager[1618]: <warn> Activation (wlan0) failed for access point (Net3)
Jun 17 09:40:12 octopus NetworkManager[1618]: <info> Marking connection 'NSU' invalid.
Jun 17 09:40:12 octopus NetworkManager[1618]: <warn> Activation (wlan0) failed.
Jun 17 09:40:12 octopus NetworkManager[1618]: <info> (wlan0): device state change: failed -> disconnected (reason 'none') [120 30 0]
Jun 17 09:40:12 octopus NetworkManager[1618]: <info> (wlan0): deactivating device (reason 'none') [0]

# Obvious questions:
1) Why are "secrets" required? All the necessary information is in the configuration files and the private key is *not* encrypted.
2) The "no agents found" message might be related to the problem, since agents not only prompt the users for secrets, but also try to get the secrets themselves (before prompting for them). Could this mean that the private key and/or certificate could not be opened by OpenSSL? How can one diagnose this issue?

Steps to reproduce:

Try to connect to an EAP-TLS wireless network with NetworkManager.

# What I tried (using NetworkManager)
1) Certificate and private key in separate PEM text files (the same way you set them up for wpa_supplicant).
2) No user certificate file and an unencrypted PKCS12 file set as private key, as described here https://vtluug.org/wiki/EAP-TLS#NetworkManager
3) The same file for both user certificate and private key, containing their PEM representations concatenated, the way you would configure the Courier mail server. (This is also one of the options recommended by the site linked above.)

Nothing worked and the error messages in messages.log were always the same.

Could it be related to this bug? https://bugs.archlinux.org/task/22149
This task depends upon

Closed by  Gerardo Exequiel Pozzi (djgera)
Tuesday, 29 March 2016, 01:58 GMT
Reason for closing:  Upstream
Comment by Greg (dolby) - Monday, 15 October 2012, 11:42 GMT
Status with NM 0.9.6.0?
Comment by Andrej Podzimek (andrej) - Thursday, 17 January 2013, 01:07 GMT
  • Field changed: Percent Complete (100% → 0%)
Status is still the same: It doesn't work. No reasonable log messages, no explanation. Since netcfg connects to the same network with no issues, NetworkManager must be buggy. I don't have frequent access to the EAP-TLS network and cannot respond instantly. Today I came back after 4 months and can confirm that 0.9.6.4-1 simply fails.
Comment by Andrej Podzimek (andrej) - Tuesday, 26 November 2013, 13:43 GMT
BTW, IPSec and OpenVPN don't work either. Both of the run 100% fine on my system when started manually, but NetworkManager just can't handle them.

This is really strange. Either NetworkManager's options are a bare wish list with no actual implementation, or there must be a hidden problem somewhere. There's nothing in the logs, unfortunately. It would be nice if NM could just say "can't read this file" or "this certificate is not trusted", but it doesn't say anything. :-(

Connections based on passwords (mostly) work, though 802.1x over ethernet fails in some versions. Whenever it comes to external files, no matter if they contain OpenVPN shared keys or RSA keys and certificates (for EAP-TLS on WiFi, for IPSec or for OpenVPN), NetworkManager just fails silently, without giving any reasons.
Comment by Andrej Podzimek (andrej) - Thursday, 25 December 2014, 02:52 GMT
I have a workaround for the EAP-TLS issue. (No news about IPSec though.) Hopefully these steps will be useful for someone facing the same problem:

0. Use a .p12 file rather than separate certificate and key files.
1. Set the same password for the private key and for the entire .p12 package (a).
2. In NetworkManager's configuration, prefix *all* file paths with file:// -- for example, file:///etc/eap/mynetwork.p12
3. Set the same .p12 file as your private key and as your client certificate.
4. Use the standard .pem text file for the CA certificate to check against, but again, don't forget the file:// prefix.
5. Don't forget to fill in the .p12 password you set above (b).
6. That's it -- you should be able to connect.

(a) Usually this happens by default if you export a .p12 from various GUI utilities, though you have much more control over it using OpenSSL.
(b) You can produce an unprotected / unencrypted .p12 file and choose the "no password needed" option, but for some reason this doesn't work.

This nicely illustrates what makes NetworkManager so (in)famous -- there seem to be easy-to-use configuration options for just about everyhing, but only a very small subset of the options actually works as intended. Quite obviously, using separate private key and client certificate files fails for some reason and so do file paths generated by the default file dialogs (i.e., without the file:// prefix). It's not really easy to figure this out. NetworkManager should clearly report what the problem is, e.g., "expected a .p12 file, found something else" etc.

Loading...