Network manager cannot connect to WPA2/PEAP/MSCHAPv2 enterprise wifi networks without CA_Certificate, like Eduroam

[zsolt.ruszinyák]

HOW TO REPRODUCE:
Connect to a MPA2/PEAP/MSCHAPv2 enterprise wifi network that doesn't use a CA Certificate, like Eduroam.

RESULT:
The computer doesn't connect, as the certificate verification fails.

WORKAROUNDS:
(http://askubuntu.com/questions/279762/cant-connect-to-wpa2-enterprise-peap)

RELEASE NOTES TEXT:
When connecting to MPA2/PEAP/MSCHAPv2 enterprise wifi networks that doesn't use a CA Certificate, like Eduroam, the connection fails (http://askubuntu.com/questions/279762/cant-connect-to-wpa2-enterprise-peap)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[hepaly (hurezi)]

I have the same problem. I can not connect to wifi network (WPA and WPA2 Enterprise PEAP, MSCHAPv2 +username/password)
The network manager doesn't accept my password. On last week, it worked well. (2013. 03.15.)

[Mathieu Trudel-Lapierre (cyphermox)]

The certificate authority is missing. You may want to add it to the configuration in NetworkManager to point to a CA certificate that can be provided to you by your network administrator:

Jan 24 21:28:21 ubuntu wpa_supplicant[3569]: wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
Jan 24 21:28:21 ubuntu wpa_supplicant[3569]: TLS: Certificate verification failed, error 20 (unable to get local issuer certificate) depth 1 for '/C=SK/L=Bratislava/O=Comenius University/CN=WWW Servers Certification Authority/emailAddress=xxxxxxxxx'
Jan 24 21:28:21 ubuntu wpa_supplicant[3569]: wlan0: CTRL-EVENT-EAP-TLS-CERT-ERROR reason=1 depth=1 subject='/C=SK/L=Bratislava/O=Comenius University/CN=WWW Servers Certification Authority/emailAddress=xxxxxxxx' err='unable to get local issuer certificate'
Jan 24 21:28:21 ubuntu wpa_supplicant[3569]: SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA
Jan 24 21:28:21 ubuntu wpa_supplicant[3569]: OpenSSL: openssl_handshake - SSL_connect error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
Jan 24 21:28:22 ubuntu wpa_supplicant[3569]: wlan0: CTRL-EVENT-EAP-FAILURE EAP authentication failed

I've noticed this too happening with self-signed certificates in universities. The alternative is to edit the connection file in /etc/NetworkManager/system-connections to remove "system-ca-certs=true".

[zsolt.ruszinyák (zsolt-ruszinyak)]

but why only since 13.04 if it worked fine so far. anyway, I have found something here, it should be the certificate, but I haven't got round to try it myself: http://www.lan.kth.se/eduroam/AddTrust_External_CA_Root.pem does it work for you, hepaly?

[hepaly (hurezi)]

Hi Zsolt, This problem affects me, when i try to connect to my office network. We never used certificate authority. The wifi network allows the connection, when I use a specific hostname, and username/password. Ubuntu 12.10 is working well. On last week, the wifi connection was OK on ubuntu 13.04.

[hepaly (hurezi)]

I got a certificate file (*.crt) from IT, and the connection is working well (with this cert. file). It is interesting, because the 12.10 works without this file.

[zsolt.ruszinyák (zsolt-ruszinyak)]

if it doesn't change, this could mean a serious move-away from ubuntu,
cause I instapped ubuntu to many of my friemds juat because they were
unaboe to connect to eduroam in windows! don't underestimate this, I would
mark this of a very high importanace, being a dev...
On Mar 19, 2013 2:02 PM, "hepaly" <email address hidden> wrote:

> I got a certificate file (*.crt) from IT, and the connection is working
> well (with this cert. file). It is interesting, because the 12.10 works
> without this file.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1104476
>
> Title:
> Network manager cannot connect to Eduroam (worldwide WiFi network for
> university students)
>
> Status in “network-manager” package in Ubuntu:
> Invalid
>
> Bug description:
> I can connect to Eduroam in 12.10 and any other previous release, but
> not in 13.04. I checked, my name and password are correct, all
> settings are the same as in 12.10.
>
> Network properties:
>
> security: WPA - WPA2 enterprise
> authentication: protected EAP (PEAP)
> CA certificate: none
> PEAP version: automatic
> inner autentication: MSCHAPv2
> username: (required)
> password: (required)
>
> ProblemType: Bug
> DistroRelease: Ubuntu 13.04
> Package: network-manager 0.9.6.0+git201301021750.e78c3e8-0ubuntu3
> ProcVersionSignature: Ubuntu 3.8.0-1.5-generic 3.8.0-rc4
> Uname: Linux 3.8.0-1-generic i686
> ApportVersion: 2.8-0ubuntu2
> Architecture: i386
> CasperVersion: 1.330
> Date: Thu Jan 24 21:32:25 2013
> IfupdownConfig:
> # interfaces(5) file used by ifup(8) and ifdown(8)
> auto lo
> iface lo inet loopback
> IpRoute:
> default via 192.168.43.1 dev wlan0 proto static
> 169.254.0.0/16 dev wlan0 scope link metric 1000
> 192.168.43.0/24 dev wlan0 proto kernel scope link src
> 192.168.43.149 metric 9
> LiveMediaBuild: Ubuntu 13.04 "Raring Ringtail" - Alpha i386 (20130123)
> MarkForUpload: True
> NetworkManager.state:
> [main]
> NetworkingEnabled=true
> WirelessEnabled=true
> WWANEnabled=true
> WimaxEnabled=true
> ProcEnviron:
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: network-manager
> UpgradeStatus: No upgrade log present (probably fresh install)
> nmcli-con:
> NAME UUID TYPE
> TIMESTAMP TIMESTAMP-REAL AUTOCONNECT
> READONLY DBUS-PATH
> AndroidAP 978da457-563b-4c59-a894-45eb0f74fcb7
> 802-11-wireless 1359063171 Thu 24 Jan 2013 09:32:51 PM UTC yes
> no /org/freedesktop/NetworkManager/Settings/2
> Wired connection 1 6703fabc-9519-49bd-a4af-45fbfb7d660e
> 802-3-ethernet 1359062570 Thu 24 Jan 2013 09:22:50 PM UTC yes
> no /org/freedesktop/NetworkManager/Settings/1
> eduroam 00f69a95-4a1b-436c-b462-a284f45fbaa1
> 802-11-wireless 1359063171 Thu 24 Jan 2013 09:32:51 PM UTC yes
> no /org/freedesktop/NetworkManager/Settings/0
> nmcli-dev:
> DEVICE TYPE ...

[Alfredo Buttari (alfredo-buttari)]

Hi Hepaly,
what kind of certificate did you use? googling around I found (here, for example https://admin.kuleuven.be/icts/english/wifi/eduroam-ubuntu) that with the

/usr/share/ca-certificates/mozilla/AddTrust_External_Root.crt

should work but instead it does not work for me.

alfredo

[hepaly (hurezi)]

Here are some screenshots about this issue:
I can connect to office network without using CA certificate file (ubuntu 12.10 live cd):
http://dl.dropbox.com/u/3104528/network_manager_issue/ubuntu12.10_wpa2E.png

Ubuntu 13.04 daily build doesn't accept my password. (using same settings, as ubuntu 12.10):
http://dl.dropbox.com/u/3104528/network_manager_issue/ubuntu13_04wpa2E.png

But if I use the CA certificate file, what I got from IT guys, then the password validation is OK, and it connects to wifi network.
http://dl.dropbox.com/u/3104528/network_manager_issue/ubuntu13_04wpa2E_ok_with_crt.png

Actually it works well using with CA certificate file, but why does the 12.10 work without this file? Is it bug or feature? :)

[zsolt.ruszinyák (zsolt-ruszinyak)]

I'm marking this again as new, cause the definition of invalid says that it should be a support request which it is not, because canonical cannot provide support to solve it.

most people don't know what a CA certificate is, so you can't leave it this way, cause they will say, that ubuntu just cannot connect and they are moving back to windows... you have to consider what normal people will think about this.

[Alfredo Buttari (alfredo-buttari)]

I've tried all sorts of certificates in the last few days (searching on google people say to use different types of them) but I couldn't make this work. Moreover the Eduroam site says to leave the certificate field empty. I can connect with my telephone with no problems so I'm sure the problem is not related to my account. I'll check if it works with an older ubuntu version asap.

[zsolt.ruszinyák (zsolt-ruszinyak)]

I have tries with different certificates (cause my school haven't issued
one) and it didn't work. currently there's no way for us to connect to
eduroam in 13.04.
On Mar 25, 2013 10:50 AM, "Alfredo Buttari" <email address hidden>
wrote:

> I've tried all sorts of certificates in the last few days (searching on
> google people say to use different types of them) but I couldn't make
> this work. Moreover the Eduroam site says to leave the certificate field
> empty. I can connect with my telephone with no problems so I'm sure the
> problem is not related to my account. I'll check if it works with an
> older ubuntu version asap.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1104476
>
> Title:
> Network manager cannot connect to Eduroam (worldwide WiFi network for
> university students)
>
> Status in “network-manager” package in Ubuntu:
> New
>
> Bug description:
> I can connect to Eduroam in 12.10 and any other previous release, but
> not in 13.04. I checked, my name and password are correct, all
> settings are the same as in 12.10.
>
> Network properties:
>
> security: WPA - WPA2 enterprise
> authentication: protected EAP (PEAP)
> CA certificate: none
> PEAP version: automatic
> inner autentication: MSCHAPv2
> username: (required)
> password: (required)
>
> ProblemType: Bug
> DistroRelease: Ubuntu 13.04
> Package: network-manager 0.9.6.0+git201301021750.e78c3e8-0ubuntu3
> ProcVersionSignature: Ubuntu 3.8.0-1.5-generic 3.8.0-rc4
> Uname: Linux 3.8.0-1-generic i686
> ApportVersion: 2.8-0ubuntu2
> Architecture: i386
> CasperVersion: 1.330
> Date: Thu Jan 24 21:32:25 2013
> IfupdownConfig:
> # interfaces(5) file used by ifup(8) and ifdown(8)
> auto lo
> iface lo inet loopback
> IpRoute:
> default via 192.168.43.1 dev wlan0 proto static
> 169.254.0.0/16 dev wlan0 scope link metric 1000
> 192.168.43.0/24 dev wlan0 proto kernel scope link src
> 192.168.43.149 metric 9
> LiveMediaBuild: Ubuntu 13.04 "Raring Ringtail" - Alpha i386 (20130123)
> MarkForUpload: True
> NetworkManager.state:
> [main]
> NetworkingEnabled=true
> WirelessEnabled=true
> WWANEnabled=true
> WimaxEnabled=true
> ProcEnviron:
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: network-manager
> UpgradeStatus: No upgrade log present (probably fresh install)
> nmcli-con:
> NAME UUID TYPE
> TIMESTAMP TIMESTAMP-REAL AUTOCONNECT
> READONLY DBUS-PATH
> AndroidAP 978da457-563b-4c59-a894-45eb0f74fcb7
> 802-11-wireless 1359063171 Thu 24 Jan 2013 09:32:51 PM UTC yes
> no /org/freedesktop/NetworkManager/Settings/2
> Wired connection 1 6703fabc-9519-49bd-a4af-45fbfb7d660e
> 802-3-ethernet 1359062570 Thu 24 Jan 2013 09:22:50 PM UTC yes
> no /org/freedesktop/NetworkManager/Settings/1
> eduroam 00f69a95-4a1b-436c-b462-a284f45fbaa1
> 802-11-wireless 1359063171 Thu 24 Jan...

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Igor Petrović (sendwhateveryouwant)]

Also unable to connect, works well in any Ubuntu version except for 13.04.

[gluca (gianluca-carlesso)]

Hi! i have same bug. The problem occurs only in 13.04.

[Eduard Gotwig (gotwig)]

I have the same problem.
Very bad.

My college, the b.i.b International College Bergisch Gladbach (www.bg.bib.de) is affected!

In 12.04 it worked perfectly!

[Eduard Gotwig (gotwig)]

If this bug does not get fixed, a whole industry is affected.

This bug has to be critical!

[Eduard Gotwig (gotwig)]

Sry, I just want to note that removing "system-ca-certs=true" from /etc/NetworkManager/system-connections solved the problem for me!

[Eduard Gotwig (gotwig)]

Remove the line that I marked (line 20) , to fix it

This is an example of my NetworkManager profile.

This file is saved under /etc/NetworkManager/system-connections/

with connecting to the wireless point at my college. (www.bg.bib.de)

[Brendan Donegan (brendan-donegan)]

So it seems the problem is system-ca-certs=true is being added despite Eduard cancelling the request for the cert.

[zsolt.ruszinyák (zsolt-ruszinyak)]

I had no possibilty of testing these days. any progress, guys?
On Apr 9, 2013 11:30 AM, "Brendan Donegan" <email address hidden>
wrote:

> So it seems the problem is system-ca-certs=true is being added despite
> Eduard cancelling the request for the cert.
>
> ** Changed in: network-manager (Ubuntu)
> Importance: Undecided => High
>
> ** Changed in: network-manager (Ubuntu)
> Status: Confirmed => Triaged
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1104476
>
> Title:
> Network manager cannot connect to WPA2/PEAP/MSCHAPv2 network without
> CA_Certificate
>
> Status in “network-manager” package in Ubuntu:
> Triaged
>
> Bug description:
> I can connect to Eduroam in 12.10 and any other previous release, but
> not in 13.04. I checked, my name and password are correct, all
> settings are the same as in 12.10.
>
> Network properties:
>
> security: WPA - WPA2 enterprise
> authentication: protected EAP (PEAP)
> CA certificate: none
> PEAP version: automatic
> inner autentication: MSCHAPv2
> username: (required)
> password: (required)
>
> ProblemType: Bug
> DistroRelease: Ubuntu 13.04
> Package: network-manager 0.9.6.0+git201301021750.e78c3e8-0ubuntu3
> ProcVersionSignature: Ubuntu 3.8.0-1.5-generic 3.8.0-rc4
> Uname: Linux 3.8.0-1-generic i686
> ApportVersion: 2.8-0ubuntu2
> Architecture: i386
> CasperVersion: 1.330
> Date: Thu Jan 24 21:32:25 2013
> IfupdownConfig:
> # interfaces(5) file used by ifup(8) and ifdown(8)
> auto lo
> iface lo inet loopback
> IpRoute:
> default via 192.168.43.1 dev wlan0 proto static
> 169.254.0.0/16 dev wlan0 scope link metric 1000
> 192.168.43.0/24 dev wlan0 proto kernel scope link src
> 192.168.43.149 metric 9
> LiveMediaBuild: Ubuntu 13.04 "Raring Ringtail" - Alpha i386 (20130123)
> MarkForUpload: True
> NetworkManager.state:
> [main]
> NetworkingEnabled=true
> WirelessEnabled=true
> WWANEnabled=true
> WimaxEnabled=true
> ProcEnviron:
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: network-manager
> UpgradeStatus: No upgrade log present (probably fresh install)
> nmcli-con:
> NAME UUID TYPE
> TIMESTAMP TIMESTAMP-REAL AUTOCONNECT
> READONLY DBUS-PATH
> AndroidAP 978da457-563b-4c59-a894-45eb0f74fcb7
> 802-11-wireless 1359063171 Thu 24 Jan 2013 09:32:51 PM UTC yes
> no /org/freedesktop/NetworkManager/Settings/2
> Wired connection 1 6703fabc-9519-49bd-a4af-45fbfb7d660e
> 802-3-ethernet 1359062570 Thu 24 Jan 2013 09:22:50 PM UTC yes
> no /org/freedesktop/NetworkManager/Settings/1
> eduroam 00f69a95-4a1b-436c-b462-a284f45fbaa1
> 802-11-wireless 1359063171 Thu 24 Jan 2013 09:32:51 PM UTC yes
> no /org/freedesktop/NetworkManager/Settings/0
> nmcli-dev:
> DEVICE TYPE STATE DBUS-PATH
> wlan0 802-11-wireless connected
> /org/f...

[Carl Davis (carl.davis)]

I can confirm that even though I choose ignore on the CA Cert dialog, the line "system-ca-certs=true" was added to system-connections. It works find after I set that to false.

[Ryan Yates (ryanyates23)]

Hey, my laptop can't even find eduroam or setup-wifi to even attempt connecting since upgrading to 13.04. How can I go about fixing this?

[zsolt.ruszinyák (zsolt-ruszinyak)]

upgrading is not good. try to fire up a usb image and try if it it can
connect in the live mode. the problem is probably with the upgrade. but
first try to connect to a hidden network.
On Apr 17, 2013 5:45 AM, "Ryan Yates" <email address hidden> wrote:

> Hey, my laptop can't even find eduroam or setup-wifi to even attempt
> connecting since upgrading to 13.04. How can I go about fixing this?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1104476
>
> Title:
> Network manager cannot connect to WPA2/PEAP/MSCHAPv2 network without
> CA_Certificate
>
> Status in “network-manager” package in Ubuntu:
> Triaged
>
> Bug description:
> I can connect to Eduroam in 12.10 and any other previous release, but
> not in 13.04. I checked, my name and password are correct, all
> settings are the same as in 12.10.
>
> Network properties:
>
> security: WPA - WPA2 enterprise
> authentication: protected EAP (PEAP)
> CA certificate: none
> PEAP version: automatic
> inner autentication: MSCHAPv2
> username: (required)
> password: (required)
>
> ProblemType: Bug
> DistroRelease: Ubuntu 13.04
> Package: network-manager 0.9.6.0+git201301021750.e78c3e8-0ubuntu3
> ProcVersionSignature: Ubuntu 3.8.0-1.5-generic 3.8.0-rc4
> Uname: Linux 3.8.0-1-generic i686
> ApportVersion: 2.8-0ubuntu2
> Architecture: i386
> CasperVersion: 1.330
> Date: Thu Jan 24 21:32:25 2013
> IfupdownConfig:
> # interfaces(5) file used by ifup(8) and ifdown(8)
> auto lo
> iface lo inet loopback
> IpRoute:
> default via 192.168.43.1 dev wlan0 proto static
> 169.254.0.0/16 dev wlan0 scope link metric 1000
> 192.168.43.0/24 dev wlan0 proto kernel scope link src
> 192.168.43.149 metric 9
> LiveMediaBuild: Ubuntu 13.04 "Raring Ringtail" - Alpha i386 (20130123)
> MarkForUpload: True
> NetworkManager.state:
> [main]
> NetworkingEnabled=true
> WirelessEnabled=true
> WWANEnabled=true
> WimaxEnabled=true
> ProcEnviron:
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: network-manager
> UpgradeStatus: No upgrade log present (probably fresh install)
> nmcli-con:
> NAME UUID TYPE
> TIMESTAMP TIMESTAMP-REAL AUTOCONNECT
> READONLY DBUS-PATH
> AndroidAP 978da457-563b-4c59-a894-45eb0f74fcb7
> 802-11-wireless 1359063171 Thu 24 Jan 2013 09:32:51 PM UTC yes
> no /org/freedesktop/NetworkManager/Settings/2
> Wired connection 1 6703fabc-9519-49bd-a4af-45fbfb7d660e
> 802-3-ethernet 1359062570 Thu 24 Jan 2013 09:22:50 PM UTC yes
> no /org/freedesktop/NetworkManager/Settings/1
> eduroam 00f69a95-4a1b-436c-b462-a284f45fbaa1
> 802-11-wireless 1359063171 Thu 24 Jan 2013 09:32:51 PM UTC yes
> no /org/freedesktop/NetworkManager/Settings/0
> nmcli-dev:
> DEVICE TYPE STATE DBUS-PATH
> wlan0 802-11-wireless connected
> /org/freedesktop/NetworkManager/Dev...

[Eduard Gotwig (gotwig)]

Ryan: Just read the log on this page...

[Pedro Nunes (nunes-p89)]

I am affected too.
Lets hope that on Monday its already fixed! :P

[cosmin (wizardelo)]

well i just tried 13.04 on a live-usb and this issue is still there:(
cannot connect to peap without CA, line "system-ca-certs=true" is stil added despite choosing no CA

[Matthew Dye (mdye)]

I believe this may be a GNOME problem. When I try it under Kubuntu and KDE, I can connect fine; while in GNOME, I cannot connect to my university (University of Missouri) wifi network.

[Ben Hilburn (bhilburn)]

Confirming that this is a really serious issue.

PEAP connection, MSCHAPv2, no certificate but with a username & password, I *cannot* connect to the network. Previous versions of Ubuntu work fine. Indeed, my credentials on another machine running 12.10 work just fine.

[mrtrick (patrick-hendrick)]

I can confirm this issue on a Lenovo T510, PEAP, MSCHAPv2, no cert. Switching to LEAP seems to hold fine. Removing system-ca-certs=true did not stabilize my connection at all. I am able to get connected, but drops every few minutes and sometimes will not connect at all.

[Fei (feisung)]

Hey Guys, this problem is quite serious!! Excitement in the morning after the upgrade on home wifi then complete dissapointment after 2hrs+ attempting to patch it :(
 Tried just about all that was posted here and was unsuccessful. eduroam and other enterprise wpa networks just don't work anymore. Please supply a quick fix...

[DeepJoy (deepjoy)]

Confirmed "system-ca-certs=true" is stil added despite choosing no CA and choosing ignore along with do not warn me again on the popup.

[zsolt.ruszinyák (zsolt-ruszinyak)]

this is the 1. ubuntu release I didn't install right after it came out.
guess why.

and by the way the workarond by Eduard Gotwig from comment #19 sadly
doesn't work here either. the line is always re-added. please explain us
better how u did it cause more people have reported here that it doesn't
work.

[Tyler (tyler.h)]

Workaround of removing "system-ca-certs=true" only works temporarily. Next time NetworkManager touches the profile, the line reappears in the profile.

[BrunoB (bruno-bak)]

How i got it working:

1. Download the AddTrust External CA Root (Base64 format) available here: http://iss.leeds.ac.uk/helpdesk/eduroam-certificates
2. Double click it and import using Gnome2 Key Storage (require sudo privileges).
3. Go to Network connections (right click con the wi-fi logo on the top right of the screen) and Add a new connection.
4. Name the new connection "eduroam"and have the SSID also "eduroam"
5. Under Wi-fi security choose "WPA 2 enterprise", Authentication: "Proteacted EAP (PEAP)", CA Certificate browse the file you downladed on step 1.
6. Username have your COMPLETE email (include @schoolname.something).
7.include your password.
Save it.
Good luck

[Franko Burolo (fburolo)]

Same problem here. And 13.04 really is the first Ubuntu where this doesn't work. And sure it IS critical!
If this is not fixed, Ubuntu will prove useless for most education (students/profs) and business users. And the bug is still unassigned since January?! Come on!

I just can't believe that the swirl direction of the BFB icon was a more important bug than this one... In terms that it was promptly addressed, unlike this one.

[vacaloca (ltirado)]

I just wanted to say that comment #19 of removing "system-ca-certs=true" from /etc/NetworkManager/system-connections also worked for me. Actually, what I did was set the statement to false. When I re-started the connection, it worked on the next try.

I also did a sudo chmod -w NUwave after the first time it connected, so that should avoid the statement from reappearing since now the file is read-only. Given the connection name, I'm at Northeastern University, which uses WPA2/PEAP/MSCHAP as well.

From /var/log/syslog upon successful authentication:

May 2 13:21:52 wpa_supplicant[1434]: wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
May 2 13:21:52 wpa_supplicant[1434]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
May 2 13:21:52 wpa_supplicant[1434]: wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
May 2 13:21:52 wpa_supplicant[1434]: wlan0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/C=US/ST=Massachusetts/L=Boston/O=Northeastern University/OU=IT/CN=wireless.neu.edu'
May 2 13:21:52 wpa_supplicant[1434]: last message repeated 2 times
May 2 13:21:52 Faraday wpa_supplicant[1434]: EAP-MSCHAPV2: Authentication succeeded

Before the statement was switched to false, syslog showed statements like:

May 2 13:02:59 wpa_supplicant[1483]: wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
May 2 13:02:59 wpa_supplicant[1483]: wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
May 2 13:02:59 wpa_supplicant[1483]: wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
May 2 13:02:59 wpa_supplicant[1483]: TLS: Certificate verification failed, error 20 (unable to get local issuer certificate) depth 0 for '/C=US/ST=Massachusetts/L=Boston/O=Northeastern University/OU=IT/CN=wireless.neu.edu'
May 2 13:02:59 wpa_supplicant[1483]: wlan0: CTRL-EVENT-EAP-TLS-CERT-ERROR reason=1 depth=0 subject='/C=US/ST=Massachusetts/L=Boston/O=Northeastern University/OU=IT/CN=wireless.neu.edu' err='unable to get local issuer certificate'
May 2 13:02:59 wpa_supplicant[1483]: SSL: SSL3 alert: write (local SSL3 detected an error):fatal:unknown CA
May 2 13:02:59 wpa_supplicant[1483]: OpenSSL: openssl_handshake - SSL_connect error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
May 2 13:02:59 wpa_supplicant[1483]: wlan0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
May 2 13:03:00 wpa_supplicant[1483]: wlan0: CTRL-EVENT-DISCONNECTED bssid=00:24:6c:e7:7b:51 reason=6

Before I had tried this, I had attempted to use the certificate that Windows 7 associated with the same NUwave wireless connection, but I was still unsuccessful at authenticating even with that. The odd thing is that a few weeks back when I tested with an Ubuntu 13.04 Beta 2 USB stick it worked fine, but stopped working at some point, and I re-tested with the USB stick today and it still failed, so at that point I knew it wasn't anything package related and stumbled across this bug and solution which fixed it! :)

[Franko Burolo (fburolo)]

The workaround works for me, too. Even without making the file read-only. I connected at my faculty's library in the early afternoon today. But I still think this is a critical issue, that could turn people away from Ubuntu.

It's very interesting what vacalola said about the old unchanged live image working once, and then not... Yet, the fact remains that this works completely fine in both 12.04 and 12.10, and just in 13.04 not.

[Fei (feisung)]

I give up... this has just got me switching to another Linux distro! Spent the whole week trying to rebuild my machine just cos of this issue... One year + of Ubuntu Love now to it's brother... Which I should state that wpa-enterprise works at time of writing that is!

[Kevin (kevin-redhat-bugs)]

Description of problem: After updating to wpa_supplicant 2.4-3 on July 1, was unable to connect to my corporate wifi access point. Subsequent downgrade to wpa_supplicant 2.3-3 fixed access problem, so I think this is a wpa_supplicant bug

Version-Release number of selected component (if applicable): wpa_supplicant 2.4-3

How reproducible: Upgrade to 2.4-3 try to access wpa/wpa2 wifi with TTLS authentication that has been working for well over a year now. Fails. Downgrade to 2.3-3 and it works again.

Steps to Reproduce: See above
1. Select network in NetworkManager
2. Does not connect
3. Keeps asking for password

Actual results:

From /etc/wpa_supplicant.log after upgrade:

wlp12s0: SME: Trying to authenticate with e0:1c:41:34:19:e9 (SSID='CICS' freq=5220 MHz)
wlp12s0: Trying to associate with e0:1c:41:34:19:e9 (SSID='CICS' freq=5220 MHz)
wlp12s0: Associated with e0:1c:41:34:19:e9
wlp12s0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=US
wlp12s0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp12s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlp12s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
wlp12s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authori
ty' hash=c3846bf24b9e93ca64274c0ec67c1ecc5e024ffcacd2d74019350e81fe546ae4
wlp12s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authori
ty' hash=c3846bf24b9e93ca64274c0ec67c1ecc5e024ffcacd2d74019350e81fe546ae4
wlp12s0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certificates.g
odaddy.com/repository/CN=Go Daddy Secure Certification Authority/serialNumber=07969287' hash=09ed6e991fc3273d8fea317d339c0204
1861973549cfa6e1558f411f11211aa3
wlp12s0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/OU=Domain Control Validated/CN=cicsnc.org' hash=598c9bcc63d9e114262181d14
dfed5372381b7ae0eb762e701b689b0e309f9b7
wlp12s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:cicsnc.org
wlp12s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:www.cicsnc.org
wlp12s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:osx.cicsnc.org
wlp12s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:osx2.cicsnc.org
SSL: SSL3 alert: write (local SSL3 detected an error):fatal:handshake failure
OpenSSL: openssl_handshake - SSL_connect error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small
wlp12s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
wlp12s0: Authentication with e0:1c:41:34:19:e9 timed out.
wlp12s0: CTRL-EVENT-DISCONNECTED bssid=e0:1c:41:34:19:e9 reason=3 locally_generated=1
wlp12s0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="CICS" auth_failures=1 duration=10 reason=AUTH_FAILED
wlp12s0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="CICS" auth_failures=2 duration=35 reason=CONN_FAILED

After downgrade:

wlp12s0: Trying to associate with e0:1c:41:34:19:e9 (SSID='CICS' freq=5220 MHz)
wlp12s0: Associated with e0:1c:41:34:19:e9
wlp12s0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp12s0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=US
wlp12s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlp12s0: ...

[Wallace (wallace-redhat-bugs)]

I'm using Fedora 22.
After updating the package wpa_supplicant 2.3 to 2.4 can not connect to the wireless network (PEAP-MSCHAPv2, no CA Certificate).

Please see this thead http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/Internal-radius-server-incompatibility-with-the-new-wpa/td-p/236602

After downgrade to 2.3 it works again.

[Major (major-redhat-bugs)]

I ran through a git bisect this morning and found that once this patch was applied, I couldn't hop on my corporate Aruba wifi network:

https://w1.fi/cgit/hostap/commit/?id=674f6c073f6f7cd9e04e5f117710f03d5e09ad63

_______________________________________________
commit 674f6c073f6f7cd9e04e5f117710f03d5e09ad63
Author: Eliad Peller <email address hidden>
Date: Wed Oct 22 08:03:56 2014 -0400

    WMM AC: Add basic ADDTS/DELTS sending functions

    Add basic implementation for ADDTS and DELTS sending
    functions.

    wpas_wmm_ac_addts() will send ADDTS request public action,
    containing TSPEC (traffic stream specification) with
    the given params.

    wpas_wmm_ac_delts() will look for the saved tspec with
    the given tid, and send DELTS public action for it.

    (Handling of ADDTS response and actually configuring the admission
    control params will be added in following patches.)

    Signed-off-by: Moshe Benji <email address hidden>
    Signed-off-by: Eliad Peller <email address hidden>
_______________________________________________

A simple 'git revert' was insufficient as additional patches have piled into these same files afterwards. :/

[Dan (dan-redhat-bugs)]

(In reply to Kevin Havener from comment #0)
> Description of problem: After updating to wpa_supplicant 2.4-3 on July 1,
> was unable to connect to my corporate wifi access point. Subsequent
> downgrade to wpa_supplicant 2.3-3 fixed access problem, so I think this is a
> wpa_supplicant bug
>
>
> Version-Release number of selected component (if applicable): wpa_supplicant
> 2.4-3
>
>
> How reproducible: Upgrade to 2.4-3 try to access wpa/wpa2 wifi with TTLS
> authentication that has been working for well over a year now. Fails.
> Downgrade to 2.3-3 and it works again.

This appears to be an OpenSSL issue, not a wpa_supplicant one:

SSL: SSL3 alert: write (local SSL3 detected an error):fatal:handshake failure
OpenSSL: openssl_handshake - SSL_connect error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small
wlp12s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed

for exmaple, see:

https://bbs.archlinux.org/viewtopic.php?id=198796
http://alicevixie.blogspot.com/2015/06/dh-key-too-small.html

[Dan (dan-redhat-bugs)]

(In reply to Wallace Hermano from comment #1)
> I'm using Fedora 22.
> After updating the package wpa_supplicant 2.3 to 2.4 can not connect to the
> wireless network (PEAP-MSCHAPv2, no CA Certificate).
>
> Please see this thead
> http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/Internal-
> radius-server-incompatibility-with-the-new-wpa/td-p/236602
>
> After downgrade to 2.3 it works again.

Your issue is likely due to wpa_supplicant enabling TLSv1.2 support (in response to recent attacks against SSLv3, TLSv1.0, and TLSv1.1, like the recent Firefox updates that disabled SSLv3 and TLSv1.0 negotiation). Unfortunately, not all RADIUS servers are prepared for that, and they accept the TLSv1.2 connection but generate a mismatching key than the supplicant does. That bug is in the RADIUS server...

There are some patches floating around that will detect this condition and fall back to the less-secure TLSv1.1 automatically, and we'll probably have to add those to Fedora until the RADIUS server vendors like Cisco, Aruba, etc catch up and fix their products.

[Dan (dan-redhat-bugs)]

(In reply to Dan Williams from comment #3)
> (In reply to Kevin Havener from comment #0)
> > Description of problem: After updating to wpa_supplicant 2.4-3 on July 1,
> > was unable to connect to my corporate wifi access point. Subsequent
> > downgrade to wpa_supplicant 2.3-3 fixed access problem, so I think this is a
> > wpa_supplicant bug
> >
> >
> > Version-Release number of selected component (if applicable): wpa_supplicant
> > 2.4-3
> >
> >
> > How reproducible: Upgrade to 2.4-3 try to access wpa/wpa2 wifi with TTLS
> > authentication that has been working for well over a year now. Fails.
> > Downgrade to 2.3-3 and it works again.
>
> This appears to be an OpenSSL issue, not a wpa_supplicant one:
>
> SSL: SSL3 alert: write (local SSL3 detected an error):fatal:handshake failure
> OpenSSL: openssl_handshake - SSL_connect error:14082174:SSL
> routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small
> wlp12s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
>
> for exmaple, see:
>
> https://bbs.archlinux.org/viewtopic.php?id=198796
> http://alicevixie.blogspot.com/2015/06/dh-key-too-small.html

More info: wpa_supplicant 2.4 may trigger this where 2.3 would not, becuase 2.4 enables some new ciphers for use with TLSv1.2, and the server may have enabled DH only for those ciphers that are now enabled.

The options are to either get your network admins to fix the DH key issue by using something > 768 bits, or to disable TLSv1.2 for now until they fix it.

But as a test, here's a wpa_supplicant with TLSv1.2 disabled by default. If you could test it on your network where you get the "dh key too small" error to see if that fixes the issue, then great, we can proceed with a more general solution. But if it doesn't fix the issue, then we'll need to dig a bit deeper and there may not be a general fix.

http://koji.fedoraproject.org/koji/taskinfo?taskID=10392924

[Major (major-redhat-bugs)]

I tried the koji build from the last comment and I'm unable to connect. With debug wpa_supplicant logs, I get:

SSL: SSL_connect:error in SSLv2/v3 read server hello A
SSL: SSL_connect:error in SSLv3 read finished A
SSL: SSL_connect:error in SSLv3 read finished A

[Kevin (kevin-redhat-bugs)]

I also tried the Koji build. Got the same error as I originally submitted:

SSL: SSL3 alert: write (local SSL3 detected an error):fatal:handshake failure
OpenSSL: openssl_handshake - SSL_connect error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small
wlp12s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed

I

[Virgilio (virgilio-redhat-bugs)]

I can also confirm that a downgrade of the wpa_supplicant package to version 2.3.3 on Fedora 22 x86_64 makes it possible again to connect to a WPA2 Enterprise/PEAP/MSCHAPV2 network, like eduroam.

[Hannes (hannes-redhat-bugs)]

I can further confirm that downgrading wpa_supplicant to 2.3.3 allowed me to immediately connect to eduroam.

[Gregor (gregor-redhat-bugs)]

I can confirm the same behavior. Immediately after downgrading the wpa_supplicant to 2.3.3 allowed me to connect to our company WIFI.

[Luiz (luiz-redhat-bugs)]

I can confirm the same behavior.

I downgraded to 2.3.3 and I was able to connect successfully to connect to the wifi, but then I upgraded the kernel to 4.1.6 and it installed an wpa_supplicant-gui and some other wpa packages, and it stopped working again.

Can I get some help identifying if the issue is from the same root cause?

Because the wpa_supplicant-gui has the same 2.4.4 version of the wpa_supplicant and I tried to downgrade the *-gui one and it failed, due to not having package available.

[Kent (kent-redhat-bugs)]

FYI: I have seen the same (or at least very similar problems). Upgrading to 2.4-3 or 2.4-4 broke my eduroam connection. Downgrading to 2.3-3 again made it work.

I talked to the people running the authentication server (Radiator) used when I log in to eduroam. They upgraded OpenSSL and a related Perl module on the server. After that, eduroam survived an upgrade to 2.4-4 on my laptop.

[Luiz (luiz-redhat-bugs)]

Solved the issue removing the wpa_supplicant, and it removed anaconda and anaconda-gui. Then I re-installed the wpa_supplicant, NetworkManager-wifi, and downgraded the wpa_supplicant.

If someday has a fix I would be very happy to un-block wpa_supplicant packages from my dnf exceptions.

[Germano (germano-redhat-bugs)]

*** Bug 1244188 has been marked as a duplicate of this bug. ***

[Germano (germano-redhat-bugs)]

Lastest wpa supplicant working with WPA Enterprise connections:
wpa_supplicant-2.3-3.fc22.x86_64

[David (david-redhat-bugs)]

(In reply to Germano Massullo from comment #15)
> Lastest wpa supplicant working with WPA Enterprise connections:
> wpa_supplicant-2.3-3.fc22.x86_64

Just to avoid confusion:

The lastest wpa supplicant that works with WPA Enterprise connections is
wpa_supplicant-2.3-3.fc22.x86_64

[Ville (ville-redhat-bugs)]

eduroam broke for me with 2.4 as well. I tried upgrading to 2.5 locally but it remained similarly broken. Works with 2.3-3.

[Ville (ville-redhat-bugs)]

*** Bug 1245766 has been marked as a duplicate of this bug. ***

[Michael (michael-redhat-bugs)]

(In reply to Gregor Fuis from comment #10)
> I can confirm the same behavior. Immediately after downgrading the
> wpa_supplicant to 2.3.3 allowed me to connect to our company WIFI.

I had the same issue. The workaround with version 2.3.3 did the trick for me as well.

(In reply to Dan Williams from comment #4)
> Your issue is likely due to wpa_supplicant enabling TLSv1.2 support (in
> response to recent attacks against SSLv3, TLSv1.0, and TLSv1.1, like the
> recent Firefox updates that disabled SSLv3 and TLSv1.0 negotiation).
> Unfortunately, not all RADIUS servers are prepared for that, and they accept
> the TLSv1.2 connection but generate a mismatching key than the supplicant
> does. That bug is in the RADIUS server...

I can confirm that updating FreeRADIUS (server/network infrastructure) to version freeradius-2.2.6-6.el6_7.x86_64 fixed the issue with wpa_supplicant as well as a (probably similar) issue with android 6.0 as described here https://code.google.com/p/android/issues/detail?id=188867#c29

I am now running wpa_supplicant-2.4-4.fc22.x86_64 on fedora and can connect successful to a WiFi using PEAP-MSCHAPv2 (with and without a server certificate check against a CA Certificate)

[Fedora (fedora-redhat-bugs)]

This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.

[Wallace (wallace-redhat-bugs)]

I'm testing Fedora 23 beta but i can't downgrade the wpa_supplicant.

[Nick (nick-redhat-bugs)]

I wouldn't bother degrading client security by forcing TLS 1.1

The fact that Google have shipped with TLS 1.2 in Android 6.0 (Marshmallow) is quickly identifying and mopping up broken authentication servers.

[Nick (nick-redhat-bugs)]

I posted in the Google issue tracker:

" suspect that you all are hitting this issue because the new version of Android is now negotiating, correctly, with TLS 1.2 and you have a broken backend.

If so, this issue should be marked as being invalid.

This applies to anybody with WPA2-Enterprise/802.1X SSIDs backed by either FreeRADIUS 2.2.6 with all TLS-based EAP types, 2.2.6 through 2.2.8 with EAP-TTLS, 3.0.7 with all TLS-based EAP types, and 3.0.7 through 3.0.9 with EAP-TTLS, or Radiator 4.14 or later when used in conjunction with Net::SSLeay 1.52 or earlier.

These unfortunately experience a critical bug where they miscalculate session keying material, the MPPE keys, when the TLS 1.2 protocol is negotiated by EAP clients (supplicant).

Clients that negotiate with the TLS 1.2 protocol version in the TLS Client Hello will not be able to get a usable association to affected wireless networks.

Two MPPE keys, the MS-MPPE-Recv-Key (MasterReceiveKey) and MS-MPPE-Send-Key (MasterSendKey), are used to derive the Master Session Key (MSK). This is absolutely essential to get a usable association.

The mismatch occurs because the client derives the correct MSK and the AP derives a different, incorrect MSK due to the incorrectly calculated MPPE keys supplied in the RADIUS Access-Accept.

This is more of an acute issue as Red Hat ship with a broken FreeRADIUS 2.2.6 package in RHEL 6.7. There is an update now to address this: https://rhn.redhat.com/errata/RHBA-2015-1829.html

CentOS 6.7 is similarly affected as it derives from Red Hat's sources.

I should also mention that there is a difference between implementing/offering TLS 1.2 or not and being intolerant to it. It is the latter that is a problem with the introduction of TLS 1.2 for EAP.

The issue above, loosely, concerns intolerance because the subsequent MPPE keys generated are miscalculated.

Deployments that continue to offer just TLS 1.0 will continue to function correctly as TLS 1.0 will be negotiated by EAP clients (supplicants) despite it offering TLS 1.2 in the client hello in their default configuration. (TLS has a version negotiation mechanism, you just need an intersection of supported versions and cipher suites.)"

[Nick (nick-redhat-bugs)]

This bug needs to be closed as NOTABUG.

[Luiz (luiz-redhat-bugs)]

Hey Nick,

I am not using Android, I am using the Fedora 23 as an SO and this error is really annoying, I tried to check which TLS version I am using and still dont have any clue.

Can you help checking or to use the TLS that doesnt error out?

[Nick (nick-redhat-bugs)]

Anywhere that is using wpa_supplicant 2.4 or later without specific configuration to disable TLS 1.2 will hit this issue with affected RADIUS servers. TLS 1.2 is rightly enabled by default.

(Android Marshmallow uses such a version of wpa_supplicant).

You can certainly disable TLS 1.2 in the configuration for wpa_supplicant if you absolutely must get a usable connection.

Do so with phase1="tls_disable_tlsv1_2=1"

Ideally though you would seek to get the RADIUS server updates to a version that isn't broken.

[Luiz (luiz-redhat-bugs)]

I am trying to understand better the last choice, I could connect with the command line, but its kind of annoying still. My version of the freeradius is this
[~] $ sudo dnf info freeradius
Last metadata expiration check performed 3:05:10 ago on Tue Nov 24 12:08:27 2015.
Pacotes instalados
Name : freeradius
Arq. : x86_64
Epoch : 0
Versão : 3.0.8
Release : 3.fc23
Tam. : 3.4 M
Repo : @System
From repo : fedora

[Michael (michael-redhat-bugs)]

I'm not sure if I get you right. Are you using Fedora as a server operating system to provide radius authentication for your network infrastructure?

TLS1.2 is the currently newest and (hopefully) most secure version of the TLS protocol and therefore it is a good choice using it. So disabling TLS1.2 is a bad idea as stated in comment #26. Use a radius server version that implements TLS1.2 correctly instead.

Version 3.0.8 is affected when using EAP-TTLS as mentioned in comment #23 so if you have trouble use a different server version or a different EAP type.

If I've got you totally wrong and you are not the network operator ask your network operator to fix the problem and remove freeradius from your notebook/workstation.

[Luiz (luiz-redhat-bugs)]

Yeah, I am a software developer using Fedora as a workstation. Unfortunately my network administrators like Windows, the solution they provided me is to use Ubuntu. If I want to use Linux. I prefer Fedora because I use it since version 13.

I removed the freeradius. The command line is not connecting anymore.
Here is my log. Any thoughts?

Successfully initialized wpa_supplicant
wlp6s0: SME: Trying to authenticate with 94:b4:0f:1b:bc:c5 (SSID='ciandt.private' freq=2462 MHz)
wlp6s0: Trying to associate with 94:b4:0f:1b:bc:c5 (SSID='ciandt.private' freq=2462 MHz)
wlp6s0: Associated with 94:b4:0f:1b:bc:c5
wlp6s0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp6s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
wlp6s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA' hash=ff856a2d251dcd88d36656f450126798cfabaade40799c722de4d2b5db36a73a
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA' hash=c27fd4b85e96d3777c68ab7df6aa4e626bf3ff8c72b1ce81d1eb78babeb1a074
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/serialNumber=lLUge2fRPkWcJe7boLSVdsKOFK8wv3MF/C=US/O=securelogin.arubanetworks.com/OU=GT28470348/OU=See www.geotrust.com/resources/cps (c)11/OU=Domain Control Validated - QuickSSL(R) Premium/CN=securelogin.arubanetworks.com' hash=47fa89956f2aa349e8814b21a7bbd64c9b597f0f192bfe073559945a7a846534
wlp6s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:securelogin.arubanetworks.com
wlp6s0: CTRL-EVENT-DISCONNECTED bssid=94:b4:0f:1b:bc:c5 reason=3 locally_generated=1
wlp6s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
wlp6s0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=BR
wlp6s0: SME: Trying to authenticate with 94:b4:0f:1b:bc:c5 (SSID='ciandt.private' freq=2462 MHz)
wlp6s0: Trying to associate with 94:b4:0f:1b:bc:c5 (SSID='ciandt.private' freq=2462 MHz)
wlp6s0: Associated with 94:b4:0f:1b:bc:c5
wlp6s0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlp6s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
wlp6s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=2 subject='/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA' hash=ff856a2d251dcd88d36656f450126798cfabaade40799c722de4d2b5db36a73a
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=1 subject='/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA' hash=c27fd4b85e96d3777c68ab7df6aa4e626bf3ff8c72b1ce81d1eb78babeb1a074
wlp6s0: CTRL-EVENT-EAP-PEER-CERT depth=0 subject='/serialNumber=lLUge2fRPkWcJe7boLSVdsKOFK8wv3MF/C=US/O=securelogin.arubanetworks.com/OU=GT28470348/OU=See www.geotrust.com/resources/cps (c)11/OU=Domain Control Validated - QuickSSL(R) Premium/CN=securelogin.arubanetworks.com' hash=47fa89956f2aa349e8814b21a7bbd64c9b597f0f192bfe073559945a7a846534
wlp6s0: CTRL-EVENT-EAP-PEER-ALT depth=0 DNS:securelogin.arubanetworks.com
wlp6s0: CTRL-EVENT-DISCONNECTED bssid=94:b4:0f:1b:bc:c5 reason=3 locally_generated=1
wlp6s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
wlp6s0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=BR
wlp6s0: SME: Trying to authenticat...

[Vincent (vincent-redhat-bugs)]

(In reply to Luiz Pegoraro from comment #29)
> I am still wondering if the issue is on wpa_supplicant or on the hardware,
> because I know a guy who has another PC using Fedora 22 with wpa_supplicant
> 2.4 that connects in the network via NetworkManager.

For F22 with wpa_supplicant 2.4 check this bug too, it seems the openssl library version matters: https://bugzilla.redhat.com/show_bug.cgi?id=1276073

> Also that configuration of the phase1, Can I set somewhere in the
> NetworkManager so I don't have to run command lines to connect to the
> network?

I got it working (F23/wpa_supplicant-2.4-7/openssl-1.0.2d-2) with a custom wpa_supplicant config and some manual steps:
network={
 ssid="corpwifi"
 key_mgmt=WPA-EAP
 eap=PEAP
 phase1="peaplabel=auto tls_disable_tlsv1_2=1"
 phase2="auth=MSCHAPV2"
 identity="***"
 password="***"
}
Unfortunately, I couldn't get the above working with the Networkmanager (/etc/wpa_supplicant/wpa_supplicant.conf and ifcg-corpwifi). The config set in /etc/wpa_supplicant/wpa_supplicant.conf wasn't used.

[Eran (eran-redhat-bugs)]

(In reply to Vincent P. from comment #30)

Sorry for the rookie questions, but:
1. Did you change /etc/wpa_supplicant/wpa_supplicant.conf or did you replace it?
2. After the change in /etc/wpa_supplicant/wpa_supplicant.conf, how am I to connect if not by the Networkmanager?

Thanks

> (In reply to Luiz Pegoraro from comment #29)
> > I am still wondering if the issue is on wpa_supplicant or on the hardware,
> > because I know a guy who has another PC using Fedora 22 with wpa_supplicant
> > 2.4 that connects in the network via NetworkManager.
>
> For F22 with wpa_supplicant 2.4 check this bug too, it seems the openssl
> library version matters: https://bugzilla.redhat.com/show_bug.cgi?id=1276073
>
> > Also that configuration of the phase1, Can I set somewhere in the
> > NetworkManager so I don't have to run command lines to connect to the
> > network?
>
> I got it working (F23/wpa_supplicant-2.4-7/openssl-1.0.2d-2) with a custom
> wpa_supplicant config and some manual steps:
> network={
> ssid="corpwifi"
> key_mgmt=WPA-EAP
> eap=PEAP
> phase1="peaplabel=auto tls_disable_tlsv1_2=1"
> phase2="auth=MSCHAPV2"
> identity="***"
> password="***"
> }
> Unfortunately, I couldn't get the above working with the Networkmanager
> (/etc/wpa_supplicant/wpa_supplicant.conf and ifcg-corpwifi). The config set
> in /etc/wpa_supplicant/wpa_supplicant.conf wasn't used.

[Vincent (vincent-redhat-bugs)]

I'm not sure if this is the right place te respond, but hey..wth.

(In reply to Eran B. from comment #31)
> (In reply to Vincent P. from comment #30)
>
> Sorry for the rookie questions, but:
> 1. Did you change /etc/wpa_supplicant/wpa_supplicant.conf or did you replace
> it?
After I did some manual testing (see next answer), I tried to update /etc/wpa_supplicant.conf with my corpwifi config and reconnect via the Networkmanager. Unfortunately, it didn't work.

> 2. After the change in /etc/wpa_supplicant/wpa_supplicant.conf, how am I to
> connect if not by the Networkmanager?
I turned off wifi via the Networkmanager. I created a new wpa_supplicant.conf in /root/ and rand some manual commands:

1. Connect to wifi:
# wpa_supplicant -f /var/log/wpa_supplicant.log -dd -P /var/run/wpa_supplicant.pid -c wpa_supplicant.conf -Dwext -iwlp3s0

2. Get an IP:
# dhclient wlp3s0

After this you should get an IP.

During my tests I fiddled with 'rfkill list all', 'rfkill unblock wifi' and 'ip l set wlp3s0 up' too, but if you get an IP with the above steps, you don't need too.

[Alberto (alberto-redhat-bugs)]

Also reported in <https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1501588>.

[Luiz (luiz-redhat-bugs)]

SOLVED TODAY!!! BY NETWORKMANAGER!! Just dnf update -y
I am so thrilled! Thanks you guys!

I guess it was a problem in firmwares, I looked into the logs and there were a lot of new packages for firmwares.

Thanks a lot, I guess saying by using Fedora 23, this can be closed now.

[Kevin (kevin-redhat-bugs)]

As the opener of this bug, I think it can be closed now. While other folks seem to have wireless problems, I don't think they are related to my problem which was fixed for me by an upgrade to our corporate wireless access points. It has continued to work after upgrading from F22 to F23 and a couple of iterations of wpa_supplicant as well.

[Dan (dan-redhat-bugs)]

Yeah, for TLSv1.2 issues updating the RADIUS server or corporate network is obviously the best choice. If that's not possible then the workaround with the supplicant config must be used, but the problem is at the RADIUS server.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Alberto Salvia Novella (es20490446e)]

The bug is still there, and happens despite the network adaptor being used.