Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1174122 - (EAP-TLS_MD5_certificate) Unable to connect to WPA2 PEAP like EDUROAM
Unable to connect to WPA2 PEAP like EDUROAM
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: wpa_supplicant (Show other bugs)
21
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2014-12-15 03:11 EST by Jan ONDREJ
Modified: 2014-12-17 04:37 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-12-17 04:36:59 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
/var/log/messages (17.07 KB, text/plain)
2014-12-15 03:11 EST, Jan ONDREJ
no flags Details

  None (edit)
Description Jan ONDREJ 2014-12-15 03:11:16 EST
Created attachment 968820 [details]
/var/log/messages

Description of problem:
Connection to EDUROAM site still failing. This is an WPA2 enterprise site. Looks like there are auth problems, but my password is OK.

Version-Release number of selected component (if applicable):
NetworkManager-0.9.10.0-14.git20140704.fc21.x86_64
NetworkManager-wifi-0.9.10.0-14.git20140704.fc21.x86_64
wpa_supplicant-2.0-12.fc21.x86_64
kernel-3.17.6-300.fc21.x86_64

How reproducible:
always

Steps to Reproduce:
1. try to connect to an WPA2 enterpries network

Actual results:
Logs are attached.


Additional info:
I am not sure, if this is a bug of wap_supplicant, NetworkManager or other component.
Worked well before upgrade to Fedora 21. On Fedora 21 unable to connect to these networks, but able to connect to other WPA PSK networks.
Comment 1 Jirka Klimes 2014-12-16 09:37:31 EST
I am able to connect to WPA2 enterprise networks just fine. Though I didn't try with eduroam (I am gonna test it when I approach a network).

According to the logs, association with AP timed out. wpa_supplicant log in debug mode might reveal more.
See https://wiki.gnome.org/Projects/NetworkManager/Debugging#wifi

Has anything else changed, such as your EDUROAM configuration, Wi-Fi card, place you connect from, etc?
Comment 2 Jan ONDREJ 2014-12-17 03:02:07 EST
Thank you. Something is wrong with openssl:

wlp2s0: Associated with 58:bc:27:bf:ab:1f
wlp2s0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp2s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
wlp2s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
wlp2s0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=SK/ST=Slovenska republika/L=Kosice/O=UPJS/OU=UPJS WiFi/CN=UPJS WiFi CA/emailAddress=wifi@upjs.sk'
TLS: Certificate verification failed, error 7 (certificate signature failure) depth 0 for '/C=SK/ST=Slovenska republika/L=Kosice/O=UPJS/OU=UPJS WiFi/CN=UPJS Radius/emailAddress=wifi@upjs.sk'
wlp2s0: CTRL-EVENT-EAP-TLS-CERT-ERROR reason=0 depth=0 subject='/C=SK/ST=Slovenska republika/L=Kosice/O=UPJS/OU=UPJS WiFi/CN=UPJS Radius/emailAddress=wifi@upjs.sk' err='certificate signature failure'
SSL: SSL3 alert: write (local SSL3 detected an error):fatal:decrypt error
OpenSSL: openssl_handshake - SSL_connect error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm
OpenSSL: pending error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
wlp2s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
wlp2s0: Authentication with 58:bc:27:bf:ab:1f timed out.
wlp2s0: CTRL-EVENT-DISCONNECTED bssid=58:bc:27:bf:ab:1f reason=3 locally_generated=1
wlp2s0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="eduroam" auth_failures=1 duration=10

Downgrade openssl from Fedora 20 helped me to connect to this network.
Switching component to openssl.

Working version of openssl: 1:openssl-1.0.1e-40.fc20.x86_64
Wrong version of openssl: 1:openssl-1.0.1j-1.fc21.x86_64
Comment 3 Tomas Mraz 2014-12-17 03:54:01 EST
Which hash algorithm does the OpenVPN server certificate use for its signature. If it is MD5, then this is WONTFIX and the server certificate needs to be updated to use SHA256 or at least SHA1. The use of MD5 in certificates is insecure and openssl in Fedora 21 and above and RHEL 7 and above will not support them by default.
Comment 4 Jan ONDREJ 2014-12-17 04:03:00 EST
Don't know, how to get a certificate from radius UDP port, but our CA for this has md5 signature:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: md5WithRSAEncryption
Comment 5 Tomas Mraz 2014-12-17 04:08:49 EST
I do not think the CA certificate is a problem here, the signature of the CA certificate is irrelevant. The actual server certificate is.

I made a mistake above with the mention of OpenVPN - it is not in play here, however the same applies to any other TLS server such as the EAP-TLS here.

The temporary workaround is to set the OPENSSL_ENABLE_MD5_VERIFY environment variable in the process that does the certificate verification.
Comment 6 Jan ONDREJ 2014-12-17 04:34:14 EST
This works:

echo "OPENSSL_ENABLE_MD5_VERIFY=1" >> /etc/sysconfig/wpa_supplicant
and then restart networking or computer.

I think you can close this bug as WONTFIX, everyone with this problem can find a solution here.
Thank you.
Comment 7 Tomas Mraz 2014-12-17 04:36:59 EST
I'll move it to wpa_supplicant also, so it can be found more easily.

Note You need to log in before you can comment on or make changes to this bug.