GNOME Bugzilla – Bug 594466
Trust the user's decision to use self-signed certificates
Last modified: 2009-10-16 02:41:19 UTC
If one wants to connect to a WPA EAP network nm-applet offers to either use system certificates or let the user pick the certificate. Certificates themselves are publicly available, thus they are no secrets and can be passed around. If one wants to connect to e.g. http://www.eduroam.org/ an international University network for students/researchers, i.e. they can log-in with their home Uni's account at other Unis, one needs a certificate chain, e.g. https://pki.pca.dfn.de/rwth-ca/pub/cacert/chain.txt If one picks that chain and supplies it to nm-applet the conenction fails: Trying to associate with 00:23:eb:39:39:32 (SSID='eduroam' freq=2412 MHz) Association request to the driver failed CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Associated with 00:23:eb:39:39:32 CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Associated with 00:23:eb:39:39:32 CTRL-EVENT-EAP-STARTED EAP authentication started CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected TLS: Certificate verification failed, error 19 (self signed certificate in certificate chain) depth 3 for '/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2' SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA OpenSSL: tls_connection_handshake - SSL_connect error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed CTRL-EVENT-EAP-FAILURE EAP authentication failed CTRL-EVENT-EAP-STARTED EAP authentication started CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected TLS: Certificate verification failed, error 19 (self signed certificate in certificate chain) depth 3 for '/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2' SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA OpenSSL: tls_connection_handshake - SSL_connect error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed CTRL-EVENT-EAP-FAILURE EAP authentication failed CTRL-EVENT-EAP-STARTED EAP authentication started CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected TLS: Certificate verification failed, error 19 (self signed certificate in certificate chain) depth 3 for '/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2' SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA OpenSSL: tls_connection_handshake - SSL_connect error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed CTRL-EVENT-EAP-FAILURE EAP authentication failed CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys wpa_supplicant however can handle the chain, i.e. the following works: --- /etc/wpa_supplicant.conf network={ ssid="eduroam" key_mgmt=WPA-EAP eap=TTLS identity="username@domain.com" anonymous_identity="anonamous@domain.com" password="XXX" ca_cert="/etc/certs/chain.pem" phase2="auth=PAP" } --- EOF --- nm-applet does not even tell the user what went wrong but just shows the settings again. Anyway, since "normal" users are not familiar with the whereabouts of the system certificates and wpa_supplicant being able to handle the chain, there should be no need to overrule the user's decision to use the certificate chain to authenticate the APs. NM should obey the user's decision. Not doing so will frustrate users because the connection simply fails. Further, if they can connect without certificates, they will do so, because of the ease, thus taking the risk of connection to a bad AP, just because NM did not accept their decision.
We don't get enough information out of the supplicant to determine the actual cause of the failure. The only way to really figure it out is to look at the detailed supplicant debug logs. Yeah, that sucks. We need to work on the supplicant's D-Bus API to be able to pass failure information back up to NetworkManager, since that's something that I've wanted for a long time, and makes life easier for users. The ability to use cert chains is being worked on the in 'cert-path' branch of NetworkManager 0.8 here: http://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=cert-paths Alternatively, you can copy the certificate into some trusted directory, and set the 'ca-path' option in the 802-1x setting in GConf to that directory, and the supplicant should be able to find the CA. So just to note, this should be fixed in NM 0.8 and the workaround should also be possible in NM 0.7.1.
This has been fixed in 0.8 with certificate paths. You can now use certificate chains. *** This bug has been marked as a duplicate of bug 569746 ***