Network-Manager fails WPA2 Enterprise configuration

Bug #445487 reported by Roman Andriadi on 2009-10-07
212
This bug affects 43 people
Affects Status Importance Assigned to Milestone
Network Manager Applet
Fix Released
Wishlist
network-manager-applet (Ubuntu)
Undecided
Unassigned
Karmic
Undecided
Unassigned
Lucid
Undecided
Unassigned

Bug Description

I've recently upgraded to Karmic from Jaunty and now got network-manager-gnome=0.8~a~git.20091002t194214.8515a07-0ubuntu1
When i configure 802.1x TLS authentication on the wired interface and fill all fields on "802.1x Security" tab, the "Apply..." button still remains inactive.
To check correctness of settings I've connected to my network using wpa_supplicant directly, so i suppose all my files and a password is ok.
Stracing nm-connection-editor shows following lines on its STDERR:
while private key password is invalid (guess it's ok):
WARNING **: Error: couldn't verify private key: 14 Failed to finalize decryption of the private key: -8023.
when password becomes valid:
WARNING **: Error: couldn't verify private key: 4 Couldn't decode certificate: -8183

asperkins (tonyperkins) wrote :

I'm having the same issue on the wireless side trying to use TLS for auth.

asperkins (tonyperkins) wrote :

My wpa_supplicant output...

CTRL-EVENT-SCAN-RESULTS
Trying to associate with 00:17:0f:d8:bc:40 (SSID='gnome' freq=2412 MHz)
Association request to the driver failed
Associated with 00:17:0f:d8:bc:40
CTRL-EVENT-EAP-STARTED EAP authentication started
OpenSSL: tls_connection_ca_cert - Failed to load root certificates error:00000000:lib(0):func(0):reason(0)
OpenSSL: pending error: error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag
OpenSSL: pending error: error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error
OpenSSL: pending error: error:0D09A00D:asn1 encoding routines:d2i_PrivateKey:ASN1 lib
OpenSSL: pending error: error:140CB00D:SSL routines:SSL_use_PrivateKey_file:ASN1 lib
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 13 (TLS) selected
OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully
CTRL-EVENT-CONNECTED - Connection to 00:17:0f:d8:bc:40 completed (auth) [id=0 id_str=]

asperkins (tonyperkins) wrote :

Sorry, I forgot to mention that by running wpa_supplicant and dhclient manually I am able to connect.

Paulus (paulmd-ya) wrote :

This bug also affects all WPA2 Enterprise connections — one simply cannot configure the connection settings :(

Šarūnas Burdulis (sarunas) wrote :

I can confirm the same problem with the same error messages in .xsession-errors. Connecting to WPA2 Ent. wi-fi with TLS auth.

While entering the private key password:
** (nm-applet:1793): WARNING **: Error: couldn't verify private key: 14 Failed to finalize decryption of the private key: -8023.

After the correct password has been entered:
** (nm-applet:1793): WARNING **: Error: couldn't verify private key: 4 Couldn't decode certificate: -8183

Same certificate/key work fine in 9.04.

network-manager 0.8~a~git.20091013t193206.679d548-0ubuntu1
network-manager-gnome 0.8~a~git.20091014t134532.4033e62-0ubuntu1

This is on a freshly installed 9.10 Netbook Remix.

I can confirm the original report.

Configure certs/keys/passwords in wpa_supplicant.conf, do "initctl stop network-manager", then run wpa_supplicant manually and everything works like a charm. Run network-manager, the applet or nm-connection-editor won't let me configure the connection, and additionally get in the way of wpa_supplicant.

It appears that newer network-manager-applet and NetworkManager checkouts from Git as of at least 2009-10-20 might fix this problem (or cherry-picking fixes if needed), as there are pertinent log entries, for instance:

nm-applet:

commit 39bf65351dd8d8dc6a5740ff0644999efddad049
Author: Dan Williams <email address hidden>
Date: Mon Oct 19 12:27:23 2009 -0700

    applet: request secrets in the applet's wireless dialog

    Somewhat broken by the libnm-glib settings service refactor,
    but it wouldn't have worked with system connections before anyway,
    since nothing explicitly requested system setting secrets from
    the wireless dialog. (The connection editor was OK)

    This commit basically refactors the population of the various
    GtkEntry widgets for secrets and the TLS private key filepicker to
    happen both at UI creation time, *and* to update them after
    getting secrets. The wireless dialog now explicitly requests
    secrets from a connection every time that connection is selected
    from the Connection: combo, and when the secrets come back populates
    the UI with them, which triggers dialog validation, which will
    then enable the Connect... button.

nm:
commit 40c91efa212219658932f36a3fb9c63ecc14aad3
Author: Dan Williams <email address hidden>
Date: Sun Oct 18 23:36:47 2009 -0700

    libnm-util: fix checking for TLS and TTLS phase2 secrets

    Two errors here; first, need_secrets_tls() was not updated correctly
    for the certificate paths changes that landed recently, and would
    have incorrectly returned "no secrets required" for the PATH scheme.

    Second, an incorrect strcmp() comparison in need_secrets_phase2()
    meant that the wrong TTLS phase2 method would get asked if it
    required secrets.

summary: - Apply button remains disabled when configuring 802.1x
+ Network-Manager fails WPA2 Enterprise configuration
Changed in network-manager-applet (Ubuntu):
status: New → Confirmed
Paulus (paulmd-ya) wrote :

I don't know when this is going to be fixed. I've got a workaround for the
network-manager-applet package. It doesn't solve the problem, it simply
enables the button.

--- ce-polkit-button.c.orig 2009-11-03 20:36:43.358540830 +0300
+++ ce-polkit-button.c 2009-11-03 20:36:52.822040847 +0300
@@ -68,7 +68,7 @@
 {
  CEPolkitButtonPrivate *priv = CE_POLKIT_BUTTON_GET_PRIVATE (self);

- gtk_widget_set_sensitive (GTK_WIDGET (self), actionable);
+ gtk_widget_set_sensitive (GTK_WIDGET (self), TRUE);

  if (priv->use_polkit && priv->authorized) {
   gtk_button_set_label (GTK_BUTTON (self), priv->auth_label);

Paulus (paulmd-ya) wrote :

I was wrong, the previous workaround doesn't solve anything, the nm-connection-editor is incapable of storing the new password :-(

The good news is I've got the new workaround for the network-manager itself, looks like this one works okay.

BenBurch (benburch) wrote :

Is there presently a work-around?

I tried forcing version to the Jaunty versions of network-manager, network-manager-dev and network-manager-gnome, and no joy. The menu appears, and it shows the networks, but have the same error with the correct password not being accepted.

I may have to re-install Jaunty.

A workaround for Karmic that I was recently pointed to is (assuming WPA2 enterprise with TLS auth and that your CA provides .p12 files - my eduroam site does):
- enter your identity as usual (this often matches what's in your user certificate)
- leave "User Certificate" blank
- provide the root signing CA 's certificate as "CA certificate" (haven't tried if "Use system CA certificates" would work)
- as Private Key, provide a .p12 file containing key and cert
- as Password, provide the password required to decrypt the .p12 file.

Forget the remark about "system CA certificates", I'd been looking at the wrong version; the one that ships with Karmic doesn't offer this.

Paulus (paulmd-ya) wrote :

You still may use my workaround patch. You may get a prebuilt package from my repo if you trust other's builds: http://repo.paulus.ru/. You need a libnm-util1 package.

dr who (dr-who) wrote :

same problem here. cannot connect to corporate WLAN :-(

mikkle (mikkle) wrote :

Problem confirmed (Lenove T61, iwlagn)

- Same here, unable to access corporate WLAN. This is a serious regression!

A colleague of mine (Thank you Francois) found a workaround that worked for me:
My situation: similar error message in .xsession-errors, wasn't able to 'apply' or select the .p12 certificate for WPA(2)-Enterprise, separate .pem files for usercert and key didn't work either.

Repackaging the original .p12 into a new .p12 with openssl did work however:

$ openssl pkcs12 -in original.p12 -out temp.pem
$ openssl pkcs12 -in temp.pem -export -name "Repackaged PKCS#12 file" -out new.p12

Selecting the .p12 file in the 'Private Key' entry, leaving the rest empty allowed me to 'apply' it and get WPA(2)-Enterprise (for eduroam) working.

Hopefully this works for others as well.

Cheers,

Remco

Thank You!

On Nov 23, 2009, at 3:16 AM, Remco Poortinga - van Wijnen wrote:

> A colleague of mine (Thank you Francois) found a workaround that worked for me:
> My situation: similar error message in .xsession-errors, wasn't able to 'apply' or select the .p12 certificate for WPA(2)-Enterprise, separate .pem files for usercert and key didn't work either.
>
> Repackaging the original .p12 into a new .p12 with openssl did work
> however:
>
> $ openssl pkcs12 -in original.p12 -out temp.pem
> $ openssl pkcs12 -in temp.pem -export -name "Repackaged PKCS#12 file" -out new.p12
>
> Selecting the .p12 file in the 'Private Key' entry, leaving the rest
> empty allowed me to 'apply' it and get WPA(2)-Enterprise (for eduroam)
> working.
>
> Hopefully this works for others as well.
>
> Cheers,
>
> Remco
>
> --
> Network-Manager fails WPA2 Enterprise configuration
> https://bugs.launchpad.net/bugs/445487
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “network-manager-applet” package in Ubuntu: Confirmed
>
> Bug description:
> I've recently upgraded to Karmic from Jaunty and now got network-manager-gnome=0.8~a~git.20091002t194214.8515a07-0ubuntu1
> When i configure 802.1x TLS authentication on the wired interface and fill all fields on "802.1x Security" tab, the "Apply..." button still remains inactive.
> To check correctness of settings I've connected to my network using wpa_supplicant directly, so i suppose all my files and a password is ok.
> Stracing nm-connection-editor shows following lines on its STDERR:
> while private key password is invalid (guess it's ok):
> WARNING **: Error: couldn't verify private key: 14 Failed to finalize decryption of the private key: -8023.
> when password becomes valid:
> WARNING **: Error: couldn't verify private key: 4 Couldn't decode certificate: -8183
>

Vince (misoul) wrote :

Thanks guys, I've spent 3hrs yesterday trying to fixing it. I used the latest image of Karmic on Dec 21. How come a bug like this stays unfixed for 2 months...hmmm...

Changed in network-manager-applet (Ubuntu Karmic):
status: New → Confirmed
tags: added: iso-testing
Vince (misoul) wrote :

I can confirm solution #15 by "Remco Poortinga - van Wijnen" works just fine for me. Thanks a lot Remco. And why haven't they released a patch to fix this? Not good.

BenBurch (benburch) wrote :

Any news of a patch?

Marc Deslauriers (mdeslaur) wrote :

I have just tested this, it is now working properly in Lucid's network-manager package. Closing Lucid task.

Changed in network-manager-applet (Ubuntu Lucid):
status: Confirmed → Fix Released
Tyrael (marco-crociani) wrote :

Yesterday I tried to connect to my university wifi network with Ubuntu Lucid Beta 2.
To connect to the network I have to use the config in the attachment but with the new version of network I can't.

David Rando (david-rando) wrote :

Hi!

Same problem as Tyrael has.

The options for key type selection on WPA-Enterprise selection don't exists.

Since i Need for my college connection to select a WPA-EAP connection with key type = TKIP, i'm unable to connect to it using network-manager, and when it does, it drops quickly. Using normal wpa_supplicant works like a charm.

Those options were previously on earlier versions of network-manager, and i see, there are a few opened bugs just because of this.

Hope anyone can give us some light about this problem.

Kai Jauch (kaijauch) wrote :

network-manager 0.8-0ubuntu3 still has this problem, it is not fixed in Lucid. The workaround works however.

Changed in network-manager-applet (Ubuntu Lucid):
status: Fix Released → Confirmed

I can confirm note #23:
Bug still exists and Workaround #15 works. In my case I had .pem files and had to convert them to .p12

With nm-connection-editor I still have problems. As workaround I avoided using it and used a system-connection file instead. See the attached example file. It works for Karmic and Lucid. HTH, Patrick

Attached a patch, which lets you use a .pem as private-key-file in nm-connection-editor. The button "Apply" should then work. I tested it in the nm-connection-editor in Karmic, but couldn't test it with wlan neither with lucid. You have to use your .pem file together with a password, otherwise network-manager refuses to use it.

Changed in network-manager-applet (Ubuntu):
status: Fix Released → Confirmed
Changed in network-manager-applet:
status: Unknown → New

There is a further easy workaround which works also with nm-connection-editor on karmic. Just concatenate your privatekey together with your cert like

  cat key.pem cert.pem > mynewkey.pem # key.pem needs to be encryted with a password!

Then use mynewkey.pem as new "private key" and the Apply button should appear
(thx to https://bugzilla.gnome.org/show_bug.cgi?id=585570#c6)

But it looks like the bug is already fixed in upstream - I have no idea if this patch is already included in Lucid or not (?):

git log NetworkManager/libnm-util/nm-setting-8021x.c
commit 4274edf47dfc1341704311d9587dc6951db480e9
Author: Dan Williams <email address hidden>
Date: Tue Dec 8 16:52:24 2009 -0800

    libnm-util: client certificate should not be required to set private key (bgo #585570)

    Not sure what I was thinking originally; there's no way this was
    correct in the first place.

David Tombs (dgtombs) wrote :

Patrick, that commit is in the Lucid version. I guess you're seeing a different issue.

BeBoxer (ubuntu-themitchells) wrote :

In Lucid I'm still seeing the issue which is addressed by the workaround in post #15. Specifically, the GUI will not load a PKCS12 file which is lacking the friendlyName attribute. The workaround in #15 adds it. This is a pretty silly bug, and might even be understandable if the GUI ever displayed the friendlyName (apparently really old versions of Netscape had a similar bug) but the GUI never even appears to use the attribute!

David Tombs (dgtombs) on 2010-08-15
tags: added: regression-release
Changed in network-manager-applet:
importance: Unknown → High
Matt Winter (mattwinter) wrote :

finally

On Thu, Sep 16, 2010 at 3:35 PM, Bug Watch Updater <
<email address hidden>> wrote:

> ** Changed in: network-manager-applet
> Importance: Unknown => High
>
> --
> Network-Manager fails WPA2 Enterprise configuration
> https://bugs.launchpad.net/bugs/445487
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Håvar Nielsen (havar) wrote :

I can confirm having this bug on a fully updated Maverick. I tried using three different network cards, none were able to connect to my schools WPA2 Enterprise network (eduroam). The network uses PEAP and MSCHAPv2.

The network cards I tried are using the modules: ipw2200, p54 and ath9k.

I am only using the default version of the packages (network-manager, wpa_supplicant, etc).

There were no problems connecting to the network in lucid.

Maverick does not seem to have any troubles connecting to either unsecured networks or my home WPA2 (AES) secured network.

I am not sure whether this bug relates to wpa_supplicant or network-manager... though I couldn't connect using wicd either. Haven't tried wpagui or manually configuring wpa_supplicant-conf-files yet, as I believe I have to disable network-manager and tweak a lot to do this and I'm currently very busy.

Håvar Nielsen (havar) wrote :

Further investigation turns out, it doesn't connect to eduroam on a liveusb version of Lucid either.

I have attached dmesg prints, iwlist scan results and the certificate for my network.

LCID Fire (lcid-fire) wrote :

For me using "Tunneled TLS" for Authentication and "PAP" for Inner Authentication does work reasonably well. It still is not nearly as stable as it's for Windows or Mac clients but since there doesn't seem to be any maintainer using an eduroam network it's probably the best we'll get.

Adrian Muraru (adi-muraru) wrote :

I can confirm that bug is occurring in Maverick as well, the workaround is to "repackage" the .p12 exported user certificate (both private and public key) as Remco Poortinga explained above.

Schlomo Schapiro (sschapiro) wrote :

We also have this issue with our corporate network (both lucid and maverick). It really is a showstopper because Ubuntu users cannot use their laptops without a network cable. This actually prevented several people from migrating their Windows laptop to Ubuntu because they use their laptop 80% in conference rooms and cannot work without the wireless connection to the corporate network.

Please make this a major bug and fix it ASAP, I will be happy to do the testing.

Schlomo, does it work however if you use the previously discussed workaround of repackaging the certificates?

What's the difference between the certificates? Is eduroam using somespecial method to issue certificates?

http://www.eduroam.org/ - note there isn't one single eduroam configuration --
I've seen setups using EAP/TLS (certificates), and I've seen setups using
PEAP/MSCHAPv2 (with login/password).

Side remark, considering how long such bugs have been open (and even Fedora 14
at point of this writing still can't connect to hidden SSID WiFi networks
without entering the root password):
  This whole NetworkManager stuff is inflicted on the world prematurely. It's
supposed to make things simple, but in practice, it's often so much more
complicated than just editing a static wpa_supplicant.conf, and if one finds
that NM is failing, it's a major hassle to get rid of and around it.

--
Matthias Andree

David Rando (david-rando) wrote :

For me right now it's working more or less, but when you have lots of networks with the same name close each other, the connection jumps from one to another disconnecting you all the time.

Schlomo Schapiro (sschapiro) wrote :

Did some more tests with a new p12 certificate and it works!

The only thing that I can tell now is that you have to fill in all fields in the settings dialogue (also the ID).

So far I only can tell sorry for my previous entry, should have done more testing before posting.

My configuration:

Ubuntu 10.10 maverick with these package versions:
$ dpkg -l | grep -E '(network-manager|wpa)'
ii network-manager 0.8.1+git.20100810t184654.ab580f4-0ubuntu2
ii network-manager-gnome 0.8.1+git.20100809t190028.290dc70-0ubuntu3
ii network-manager-pptp 0.8.1+git.20100810t192516.1e6db5a-0ubuntu1
ii network-manager-pptp-gnome 0.8.1+git.20100810t192516.1e6db5a-0ubuntu1
ii wpasupplicant 0.6.10-2

We will now start a roll-out with .p12 certificates and TLS, I will report back if any new issues arise.

AndyL (thelees-andy) wrote :

I have had this same problem on our corporate network (PEAP/MSCHAPv2) for so long now, I almost don't notice the smirks and eyerolls when I have to scrounge for a wired connection in a conference room.

Is there a way to use something akin to the p12 workaround in the PEAP/MSCHAPv2 (login/password) case?

Is this bug still active or has it been relegated to the trash bin? I've been living with this issue for months now. Can anyone confirm that this has been fixed in the 10.10? As previously posted, this is only relevant to PEAP/MSCHAPv2 networks, unfortunately I spent a majority of my day in that environment.

Any information on this would be appreciated.

Daniel Kulesz (kuleszdl) wrote :

Can we do something to get the QA-Teams attention on this bug, so it will get finally fixed in 11.04?

I just tried to reproduce this bug with the instructions given above both on a fully updated 10.04 and 10.10 and it failed in BOTH environments, with the described symptom: The "apply" button remained grayed out.

I am also using eduroam, but as Matthias pointed out the issue only affects the "PEAP/MSCHAPv2" mode. Luckily our network meanwhile supports also the "Tunneled TLS/PAP" mode, so I am not affected anymore. But nevertheless it's a shame that this high-prio bug seems still unfixed.

Is there some escalation level we can trigger for this issue?

Unfortunately there are many things that can go wrong when handling the certificates, security levels, and all of that.

I also don't happen to have a way to reproduce the required environment, so no possibility for me to easily reproduce and work on a fix. What *would* be helpful though would be if you could test it now in Natty if it wasn't already done, since there has been so many bug fixes applied in the updated packages.

Please also make sure you can still use the workaround in comment #15?

Daniel Kulesz (kuleszdl) wrote :

Here we go. I have just set up a Virtual Machine and booted 11.04-alpha3 inside it. Then I configured a Wireless connection with WPA2-Enterprise with PEAP/MSCHAPv2. As you can see in the attached screenshot, the apply button (in 11.04 it is named "save" now) remains grayed out, although all information has been provided.

Daniel Kulesz (kuleszdl) wrote :

Sorry, my fault. Please ignore my last two postings. The Button remains grayed out, because I did not enter/select an SSID name. With the name provided, the button is not grayed out anymore - neither on 10.04, nor 10.10 nor 11.04-alpha3.

Unfortunately I can't test what happens when you click it, because I have no proper auth environment set up here.

But maybe someone else has?

David Tombs (dgtombs) wrote :

Anybody still experiencing this bug should file a new report with specific steps to reproduce. This bug has gotten too confused to be useful anymore.

Changed in network-manager-applet (Ubuntu):
status: Confirmed → Invalid
Changed in network-manager-applet:
status: New → Invalid
Changed in network-manager-applet:
importance: High → Unknown
status: Invalid → Unknown
Changed in network-manager-applet:
importance: Unknown → Wishlist
status: Unknown → In Progress
Rolf Leggewie (r0lf) wrote :

karmic has seen the end of its life and is no longer receiving any updates. Marking the karmic task for this ticket as "Won't Fix".

Changed in network-manager-applet (Ubuntu Karmic):
status: Confirmed → Won't Fix
Rolf Leggewie (r0lf) wrote :

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".

Changed in network-manager-applet (Ubuntu Lucid):
status: Confirmed → Won't Fix
Changed in network-manager-applet:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Patches

Remote bug watches

Bug watches keep track of this bug in other bug trackers.