Can no longer connect to eap-tls wifi network after upgrade to f39

Ask Fedora
, , ,
1

After upgrading to Fedora 39 beta, I can no longer connect to our corporate eap-tls wifi network. Everything worked fine with Fedora 38. dmesg is not very helpful for debugging, so any suggestions where to look?

Here is the relevant dmesg output:

[Thu Oct  5 13:35:27 2023] wlp0s20f3: authenticate with 12:34:56:78:9a:bc
[Thu Oct  5 13:35:27 2023] wlp0s20f3: send auth to 12:34:56:78:9a:bc (try 1/3)
[Thu Oct  5 13:35:27 2023] wlp0s20f3: authenticated
[Thu Oct  5 13:35:27 2023] wlp0s20f3: associate with 12:34:56:78:9a:bc (try 1/3)
[Thu Oct  5 13:35:27 2023] wlp0s20f3: RX AssocResp from 12:34:56:78:9a:bc (capab=0x11 status=0 aid=3)
[Thu Oct  5 13:35:28 2023] wlp0s20f3: associated
[Thu Oct  5 13:35:28 2023] wlp0s20f3: Limiting TX power to 30 (30 - 0) dBm as advertised by 12:34:56:78:9a:bc
[Thu Oct  5 13:35:31 2023] wlp0s20f3: deauthenticating from 12:34:56:78:9a:bc by local choice (Reason: 3=DEAUTH_LEAVING)
[Thu Oct  5 13:35:43 2023] wlp0s20f3: authenticate with 12:34:56:78:9a:bc
[Thu Oct  5 13:35:43 2023] wlp0s20f3: send auth to 12:34:56:78:9a:bc (try 1/3)
[Thu Oct  5 13:35:43 2023] wlp0s20f3: authenticated
[Thu Oct  5 13:35:43 2023] wlp0s20f3: associate with 12:34:56:78:9a:bc (try 1/3)
[Thu Oct  5 13:35:43 2023] wlp0s20f3: RX AssocResp from 12:34:56:78:9a:bc (capab=0x11 status=0 aid=3)
[Thu Oct  5 13:35:43 2023] wlp0s20f3: associated
[Thu Oct  5 13:35:43 2023] wlp0s20f3: Limiting TX power to 30 (30 - 0) dBm as advertised by 12:34:56:78:9a:bc
[Thu Oct  5 13:35:46 2023] wlp0s20f3: deauthenticating from 12:34:56:78:9a:bc by local choice (Reason: 3=DEAUTH_LEAVING)
[Thu Oct  5 13:35:52 2023] wlp0s20f3: authenticate with 12:34:56:78:9a:bc
[Thu Oct  5 13:35:52 2023] wlp0s20f3: send auth to 12:34:56:78:9a:bc (try 1/3)
[Thu Oct  5 13:35:52 2023] wlp0s20f3: authenticated
[Thu Oct  5 13:35:52 2023] wlp0s20f3: associate with 12:34:56:78:9a:bc (try 1/3)
[Thu Oct  5 13:35:52 2023] wlp0s20f3: RX AssocResp from 12:34:56:78:9a:bc (capab=0x11 status=0 aid=3)
[Thu Oct  5 13:35:53 2023] wlp0s20f3: associated
[Thu Oct  5 13:35:53 2023] wlp0s20f3: Limiting TX power to 30 (30 - 0) dBm as advertised by 12:34:56:78:9a:bc
[Thu Oct  5 13:35:56 2023] wlp0s20f3: deauthenticating from 12:34:56:78:9a:bc by local choice (Reason: 3=DEAUTH_LEAVING)
[Thu Oct  5 13:36:21 2023] wlp0s20f3: authenticate with 12:34:56:78:9a:bc
[Thu Oct  5 13:36:21 2023] wlp0s20f3: send auth to 12:34:56:78:9a:bc (try 1/3)
[Thu Oct  5 13:36:21 2023] wlp0s20f3: authenticated
[Thu Oct  5 13:36:21 2023] wlp0s20f3: associate with 12:34:56:78:9a:bc (try 1/3)
[Thu Oct  5 13:36:21 2023] wlp0s20f3: RX AssocResp from 12:34:56:78:9a:bc (capab=0x11 status=0 aid=3)
[Thu Oct  5 13:36:21 2023] wlp0s20f3: associated
[Thu Oct  5 13:36:21 2023] wlp0s20f3: Limiting TX power to 30 (30 - 0) dBm as advertised by 12:34:56:78:9a:bc
[Thu Oct  5 13:36:24 2023] wlp0s20f3: deauthenticating from 12:34:56:78:9a:bc by local choice (Reason: 3=DEAUTH_LEAVING)

and here the /etc/NetworkManager/system-connections/corporate-wifi.nmconnection:

[connection]
id=corporate-wlan
uuid=23123456-789a-bcd1-2334-45678ab123bd
type=wifi
interface-name=wlp0s20f3

[wifi]
mode=infrastructure
ssid=corporate-wlan

[wifi-security]
key-mgmt=wpa-eap

[802-1x]
client-cert=/home/laolux/Documents/keys_etc/user-cert.pem
eap=tls;
identity=userid23456
private-key=/home/laolux/Documents/keys_etc/user-privkey.pem
private-key-password=a

[ipv4]
method=auto

[ipv6]
addr-gen-mode=default
method=auto

[proxy]

Any help debugging the problem will be highly appreciated!

2

Does journalctl provides more logs?

3

Sure, see here: https://paste.centos.org/view/0d44c8e3

I noticed this:

Oct 11 12:48:26 localhost wpa_supplicant[1953]: SSL: SSL3 alert: write (local SSL3 detected an error):fatal:protocol version
Oct 11 12:48:26 localhost wpa_supplicant[1953]: OpenSSL: openssl_handshake - SSL_connect error:0A000102:SSL routines::unsupported protocol

How can I check which protocol is causing issues?
Note that I have set the crypto policies to LEGACY:

# update-crypto-policies --show
LEGACY
# update-crypto-policies --check
The configured policy matches the generated policy
# update-crypto-policies --is-applied
The configured policy is applied

The crypto policies have been set many reboots ago and not touched since, so this discussion does not quite apply I think.

4

New openssl version seems to be the issue: openssl 3.1 release notes state that TLS 1.0 and some others only work when setting security level 0. This can be done here: /etc/crypto-policies/back-ends/openssl.config, set SECLEVEL=0. A reboot later everything is working again!

2 Likes
5

Thank you for this. It was driving me crazy