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
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
|
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
Tuesday, 29 March 2016, 01:58 GMT
Reason for closing: Upstream
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.
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.