Bugzilla – Bug 1101251
wpa_supplicant fails to use PEM files from network manager
Last modified: 2018-10-11 12:32:34 UTC
When a networkmanager network configure as EAP-TLS is used with an encrypted user key, the wifi fails to connect. Examining the logs, this is because wpa_supplicant/openssl treats all input as pkcs12 files - even though PEM encrypted files are supported. Work around is to use pkcs12 files for private keys. Set priority to major as this may break known working configurations on update. To test, attempt to use EAP-TLS with an encrypted user.key wpa_supplicant-2.6-4.3.x86_64 1531649151.594846: OpenSSL: SSL_use_certificate_file (PEM) --> OK 1531649151.595567: OpenSSL: tls_read_pkcs12 - Failed to use PKCS#12 file error:0D0680A8:asn1 encoding routines:asn1_check_tlen:wrong tag 1531649151.595627: OpenSSL: pending error: error:0D07803A:asn1 encoding routines:asn1_item_embed_d2i:nested asn1 error 1531649151.595640: OpenSSL: tls_connection_private_key - Failed to load private key error:00000000:lib(0):func(0):reason(0) 1531649151.595647: TLS: Failed to load private key '/home/william/secure/user_cert/user.enc.pem' 1531649151.595655: TLS: Failed to set TLS connection parameters 1531649151.595702: ENGINE: engine deinit 1531649151.595710: EAP-TLS: Failed to initialize SSL. 1531649151.595721: wlp3s0: EAP: Failed to initialize EAP method: vendor 0 method 13 (TLS) 1531649151.595729: EAP: Building EAP-Nak (requested type 13 vendor=0 method=0 not allowed) 1531649151.595739: EAP: allowed methods - hexdump(len=0):
This seems to be the same bug as https://bugs.archlinux.org/task/54233 A working patch has been discussed here (https://bugs.archlinux.org/task/54233#comment158109), but has since been dropped, as it works with newer versions of OpenSSL.
isn't this a duplicate of the already fixed bug#1099835
Yes, seems like it. The corresponding upstream fix is f665c93e1d28fbab3d9127a8c3985cc32940824f, which is already applied to our package in "wpa_supplicant-bnc-1099835-fix-private-key-password.patch". Therefore I'm closing the bug. *** This bug has been marked as a duplicate of bug 1099835 ***