Starting in the past 2 or 3 weeks, I am no longer able to authenticate to any EAP connections (Wireless using EAP-TLS, Wireless using PEAP, or wired using 802.1x).
When I try to connect, I see the following in /var/log/wpa_supplicant.log:
1780423868.304286: wlp0s20f3: Removed BSSID a6:46:8d:29:0d:a8 from ignore list (clear)
1780423868.304492: wlp0s20f3: SME: Trying to authenticate with a6:46:8d:29:0d:a8 (SSID='CCS-TLS-A' freq=5745 MHz)
1780423868.335350: wlp0s20f3: Trying to associate with a6:46:8d:29:0d:a8 (SSID='CCS-TLS-A' freq=5745 MHz)
1780423868.352923: wlp0s20f3: Associated with a6:46:8d:29:0d:a8
1780423868.353029: wlp0s20f3: CTRL-EVENT-EAP-STARTED EAP authentication started
1780423868.353160: wlp0s20f3: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
1780423868.365007: wlp0s20f3: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=13
1780423868.365241: OpenSSL: tls_connection_ca_cert - Failed to load root certificates error:8000000D:system library::Permission denied
1780423868.365267: OpenSSL: pending error: error:10080002:BIO routines::system lib
1780423868.365280: OpenSSL: pending error: error:05880020:x509 certificate routines::BIO lib
1780423868.365305: OpenSSL: tls_load_ca_der - Failed load CA in DER format error:8000000D:system library::Permission denied
1780423868.365321: OpenSSL: pending error: error:10080002:BIO routines::system lib
1780423868.365332: OpenSSL: pending error: error:05880020:x509 certificate routines::BIO lib
1780423868.365342: TLS: Failed to set TLS connection parameters
1780423868.365363: EAP-TLS: Failed to initialize SSL.
1780423868.365379: wlp0s20f3: EAP: Failed to initialize EAP method: vendor 0 method 13 (TLS)
1780423868.370610: wlp0s20f3: CTRL-EVENT-EAP-FAILURE EAP authentication failed
1780423868.410531: wlp0s20f3: CTRL-EVENT-DISCONNECTED bssid=a6:46:8d:29:0d:a8 reason=23
1780423868.410606: wlp0s20f3: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="CCS-TLS-A" auth_failures=1 duration=10 reason=AUTH_FAILED
1780423868.410625: wlp0s20f3: Added BSSID a6:46:8d:29:0d:a8 into ignore list, ignoring for 10 seconds
1780423868.410650: wlp0s20f3: BSSID a6:46:8d:29:0d:a8 ignore list count incremented to 2, ignoring for 10 seconds
1780423868.410656: wlp0s20f3: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="CCS-TLS-A" auth_failures=2 duration=36 reason=CONN_FAILED
1780423868.410800: nl80211: Failed to open /proc/sys/net/ipv4/conf/wlp0s20f3/drop_unicast_in_l2_multicast: Read-only file system
1780423868.410807: nl80211: Failed to set IPv4 unicast in multicast filter
As far as I know, the only change since this worked was applying normal updates (i.e. “zypper dup”).
How do we find and fix this problem?
This seems to be likely to be the issue. I would probably start by looking at the root certificates on the system and see what the permissions are set to.
Maybe look at /var/lib/ca-certificates/openssl/ and /var/lib/ca-certificates/ca-bundle.pem and see what the permissions are. On my system, here’s what I see:
$ ls -ld /var/lib/ca-certificates/ca-bundle.pem ; ls -ld /var/lib/ca-certificates/openssl
-r--r--r-- 1 root root 220111 May 8 10:55 /var/lib/ca-certificates/ca-bundle.pem
dr-xr-xr-x 1 root root 18502 May 8 10:55 /var/lib/ca-certificates/openssl/
Mine looks the same:
ls -ld /var/lib/ca-certificates/ca-bundle.pem ; ls -ld /var/lib/ca-certificates/openssl
-r--r--r-- 1 root root 219817 2026-06-02 10:52:44 /var/lib/ca-certificates/ca-bundle.pem
dr-xr-xr-x 2 root root 28672 2026-06-02 10:52:44 /var/lib/ca-certificates/openssl
Are you set up with SELinux or Apparmor enabled?
Otherwise, it’s going to take some deeper digging to see if there’s some other root certificate file that you’re using. I’m not using EAP, so I’m not sure where that might be - hopefully someone else with some experience with this can hop in and help.
I am using AppArmor. I do not see any useful messages from AppArmor, just:
KHolloway@Ken-System76:~>sudo journalctl -u apparmor -f
Jun 02 10:55:03 Ken-System76 systemd[1]: Starting Load AppArmor profiles...
Jun 02 10:55:03 Ken-System76 apparmor.systemd[1825]: Restarting AppArmor
Jun 02 10:55:03 Ken-System76 apparmor.systemd[1825]: Reloading AppArmor profiles
Jun 02 10:55:04 Ken-System76 systemd[1]: Finished Load AppArmor profiles.
Let’s take a look and see if there’s anything in dmesg with sudo dmesg | grep -i apparmor.
KHolloway@Ken-System76:~>sudo dmesg | grep -i apparmor
[ 0.000000] [ T0] Command line: BOOT_IMAGE=/vmlinuz-7.0.10-2-default root=/dev/mapper/f13System-f13Root splash=verbose quiet security=apparmor mitigations=auto libata.allow_tpm=1 rd.driver.blacklist=nouveau
[ 0.026834] [ T0] Kernel command line: BOOT_IMAGE=/vmlinuz-7.0.10-2-default root=/dev/mapper/f13System-f13Root splash=verbose quiet security=apparmor mitigations=auto libata.allow_tpm=1 rd.driver.blacklist=nouveau
[ 0.081898] [ T0] AppArmor: AppArmor initialized
[ 0.443244] [ T1] AppArmor: AppArmor Filesystem Enabled
[ 1.359387] [ T1] AppArmor: AppArmor sha256 policy hashing enabled
[ 1.562139] [ T1] evm: security.apparmor
[ 1.936860] [ T1] systemd[1]: systemd 260.1+suse.7.g1e45daa2fb running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE -SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK -BTF -XKBCOMMON -UTMP +LIBARCHIVE)
[ 14.056207] [ T1] systemd[1]: systemd 260.1+suse.7.g1e45daa2fb running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE -SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK -BTF -XKBCOMMON -UTMP +LIBARCHIVE)
[ 15.551763] [ T156] audit: type=1400 audit(1780503021.717:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="vscode" pid=1899 comm="apparmor_parser"
[ 15.551783] [ T156] audit: type=1400 audit(1780503021.717:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="cam" pid=1894 comm="apparmor_parser"
[ 15.551808] [ T156] audit: type=1400 audit(1780503021.717:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="ch-checkns" pid=1895 comm="apparmor_parser"
[ 15.551827] [ T156] audit: type=1400 audit(1780503021.717:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="buildah" pid=1892 comm="apparmor_parser"
[ 15.551853] [ T156] audit: type=1400 audit(1780503021.717:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="Discord" pid=1881 comm="apparmor_parser"
[ 15.551900] [ T156] audit: type=1400 audit(1780503021.717:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="brave" pid=1891 comm="apparmor_parser"
[ 15.551901] [ T156] audit: type=1400 audit(1780503021.717:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="chromium" pid=1898 comm="apparmor_parser"
[ 15.551907] [ T156] audit: type=1400 audit(1780503021.717:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="balena-etcher" pid=1887 comm="apparmor_parser"
[ 15.551933] [ T156] audit: type=1400 audit(1780503021.717:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="ch-run" pid=1896 comm="apparmor_parser"
[ 15.551961] [ T156] audit: type=1400 audit(1780503021.717:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="busybox" pid=1893 comm="apparmor_parser"
KHolloway@Ken-System76:~>
OK, nothing there unexpected that I can see. One other thing to check is sudo journalctl -b | grep -i audit - does that turn up anything? (I would expect not, but want to rule it out).
KHolloway@Ken-System76:~>sudo journalctl -b | grep -i audit
Jun 03 09:10:08 Ken-System76 kernel: audit: initializing netlink subsys (disabled)
Jun 03 09:10:08 Ken-System76 kernel: audit: type=2000 audit(1780503005.036:1): state=initialized audit_enabled=0 res=1
Jun 03 09:10:08 Ken-System76 systemd[1]: systemd 260.1+suse.7.g1e45daa2fb running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE -SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK -BTF -XKBCOMMON -UTMP +LIBARCHIVE)
Jun 03 09:10:08 Ken-System76 systemd-journald[355]: Collecting audit messages is disabled.
Jun 03 09:10:20 Ken-System76 systemd[1]: systemd 260.1+suse.7.g1e45daa2fb running in system mode (+PAM +AUDIT +SELINUX +APPARMOR +IMA +IPE -SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK -BTF -XKBCOMMON -UTMP +LIBARCHIVE)
Jun 03 09:10:20 Ken-System76 systemd-journald[1588]: Collecting audit messages is disabled.
Jun 03 09:10:21 Ken-System76 kernel: audit: type=1400 audit(1780503021.717:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="vscode" pid=1899 comm="apparmor_parser"
Jun 03 09:10:21 Ken-System76 kernel: audit: type=1400 audit(1780503021.717:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="cam" pid=1894 comm="apparmor_parser"
Jun 03 09:10:21 Ken-System76 kernel: audit: type=1400 audit(1780503021.717:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="ch-checkns" pid=1895 comm="apparmor_parser"
Jun 03 09:10:21 Ken-System76 kernel: audit: type=1400 audit(1780503021.717:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="buildah" pid=1892 comm="apparmor_parser"
Jun 03 09:10:21 Ken-System76 kernel: audit: type=1400 audit(1780503021.717:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="Discord" pid=1881 comm="apparmor_parser"
Jun 03 09:10:21 Ken-System76 kernel: audit: type=1400 audit(1780503021.717:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="brave" pid=1891 comm="apparmor_parser"
Jun 03 09:10:21 Ken-System76 kernel: audit: type=1400 audit(1780503021.717:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="chromium" pid=1898 comm="apparmor_parser"
Jun 03 09:10:21 Ken-System76 kernel: audit: type=1400 audit(1780503021.717:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="balena-etcher" pid=1887 comm="apparmor_parser"
Jun 03 09:10:21 Ken-System76 kernel: audit: type=1400 audit(1780503021.717:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="ch-run" pid=1896 comm="apparmor_parser"
Jun 03 09:10:21 Ken-System76 kernel: audit: type=1400 audit(1780503021.717:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="busybox" pid=1893 comm="apparmor_parser"
Jun 03 09:10:21 Ken-System76 systemd[1]: Starting Load Audit Rules...
Jun 03 09:10:21 Ken-System76 systemd[1]: audit-rules.service: Deactivated successfully.
Jun 03 09:10:21 Ken-System76 systemd[1]: Finished Load Audit Rules.
Jun 03 09:10:21 Ken-System76 systemd[1]: Starting Security Audit Logging Service...
Jun 03 09:10:22 Ken-System76 auditd[2109]: No plugins found, not dispatching events
Jun 03 09:10:22 Ken-System76 auditd[2109]: Init complete, auditd 4.0.2 listening for events (startup state enable)
Jun 03 09:10:22 Ken-System76 systemd[1]: Started Security Audit Logging Service.
Jun 03 09:38:42 Ken-System76 NetworkManager[2442]: <info> [1780504722.6169] audit: op="statistics" interface="eno0" ifindex=2 args="2000" pid=3514 uid=1000 result="success"
Jun 03 09:38:44 Ken-System76 NetworkManager[2442]: <info> [1780504724.9404] audit: op="connection-activate" uuid="47eca2f7-dd10-4847-8df6-95efc226bfd1" name="Clare Computer Solutions (TLS)" pid=3514 uid=1000 result="success"
Jun 03 09:40:25 Ken-System76 NetworkManager[2442]: <info> [1780504825.8203] audit: op="statistics" interface="eno0" ifindex=2 args="2000" pid=3514 uid=1000 result="success"
Jun 03 10:37:51 Ken-System76 NetworkManager[2442]: <info> [1780508271.1616] audit: op="device-managed" interface="cscotun0" ifindex=8 args="true" pid=34413 uid=0 result="success"
Jun 03 10:37:51 Ken-System76 NetworkManager[2442]: <info> [1780508271.1641] audit: op="device-reapply" interface="cscotun0" ifindex=8 args="ipv4.dns,ipv4.dns-priority,ipv4.dns-search,ipv6.dns-search" pid=34413 uid=0 result="success"
KHolloway@Ken-System76:~>
I wonder if it’s not using the global ca bundle - can you take a look in the /etc/NetworkManager/system-connections/ files and see if there’s any reference to a ca-cert path that points somewhere other than the system default?
[802-1x]
ca-cert=/home/KHolloway/Unison/Clients/c/Clare_Computer_Solutions/CCS-DC2.Clarecomputer.com_Clare Computer Solutions CA.pem
client-cert=/home/KHolloway/Unison/Clients/c/Clare_Computer_Solutions/KHolloway-Linux.ClareComputer.com.pem
eap=tls;
identity=KHolloway
private-key=/home/KHolloway/Unison/Clients/c/Clare_Computer_Solutions/KHolloway-Linux.ClareComputer.com.key
private-key-password-flags=1
KHolloway@Ken-System76:~>namei -l "/home/KHolloway/Unison/Clients/c/Clare_Computer_Solutions/CCS-DC2.Clarecomputer.com_Clare Computer Solutions CA.pem"
f: /home/KHolloway/Unison/Clients/c/Clare_Computer_Solutions/CCS-DC2.Clarecomputer.com_Clare Computer Solutions CA.pem
drwxr-xr-x root root /
dr-xr-xr-x root root home
drwx--x--- KHolloway users KHolloway
drwx------ KHolloway users Unison
drwxr-xr-x KHolloway users Clients
drwxr-xr-x KHolloway users c
drwxr-xr-x KHolloway users Clare_Computer_Solutions
-rw-r--r-- KHolloway users CCS-DC2.Clarecomputer.com_Clare Computer Solutions CA.pem
KHolloway@Ken-System76:~>
Since NetworkManager and wpa_supplicant both run as root, they shouldn’t have any trouble accessing that file, right?
KHolloway@Ken-System76:~>ps aux | grep -E "NetworkManager|wpa_supplicant"
root 2442 0.0 0.0 559240 7392 ? Ssl 09:10 0:14 /usr/sbin/NetworkManager --no-daemon
root 2601 0.0 0.0 18956 2504 ? Ss 09:10 0:02 /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -u -t -f /var/log/wpa_supplicant.log
The .pem file is readable by group and world, so that shouldn’t be a problem, and I’m sure if you tried to cat it as root, you’d see the contents.
Oh, wait…looking at the audit log, it looks like audit logging is disabled, so this is possibly still an apparmor issue. That really would be the only thing in a configuration like this that would prevent root from being able to read the file.
What do you get if you run sudo aa-complain /usr/sbin/wpa_supplicant and then try connecting?
sudo aa-complain /usr/sbin/wpa_supplicant
made it work. So, I guess that means that AppArmor is causing the problem, but not logging it? I would think we want it to log. Is there a way to turn audit on (and would that cause any problems)?
Then, step 2 will be to get it to allow?
So it seems that it’s not logging it because you’ve got audit logging turned off (this is actually in the journalctl output you shared, and I missed it the first time around:
Jun 03 09:10:08 Ken-System76 kernel: audit: initializing netlink subsys (disabled)
Jun 03 09:10:08 Ken-System76 kernel: audit: type=2000 audit(1780503005.036:1): state=initialized audit_enabled=0 res=1
...
Jun 03 09:10:08 Ken-System76 systemd-journald[355]: Collecting audit messages is disabled.
So you can switch this back to enforce mode for wpa_supplicant with:
sudo aa-enforce /usr/sbin/wpa_supplicant
And then either move the certificates into /etc/ somewhere that’s included (maybe under /etc/pki/), or you can add/modify the AppArmor profile to allow wpa_supplicant to access them in the directory you’ve stored them in in your home directory.
From what I have been able to find out, it would probably be adding a file at /etc/apparmor.d/usr.sbin.wpa_supplicant and then adding a rule to that file to allow read access to the directory. I’ve not done anything like this before, but my understanding is that the file may only need to have this in it:
/home/KHolloway/Unison/Clients/c/Clare_Computer_Solutions/* r,
But there may be more to it than that. Once the change is in place, restart apparmor and you should be good to go.
So it seems that it’s not logging it because you’ve got audit logging turned off (this is actually in the journalctl output you shared, and I missed it the first time around:
Jun 03 09:10:08 Ken-System76 kernel: audit: initializing netlink subsys (disabled)
Jun 03 09:10:08 Ken-System76 kernel: audit: type=2000 audit(1780503005.036:1): state=initialized audit_enabled=0 res=1
...
Jun 03 09:10:08 Ken-System76 systemd-journald[355]: Collecting audit messages is disabled.
So you can switch this back to enforce mode for wpa_supplicant with:
sudo aa-enforce /usr/sbin/wpa_supplicant
And then either move the certificates into /etc/ somewhere that’s included (maybe under /etc/pki/), or you can add/modify the AppArmor profile to allow wpa_supplicant to access them in the directory you’ve stored them in in your home directory.
From what I have been able to find out, it would probably be adding a file at /etc/apparmor.d/usr.sbin.wpa_supplicant and then adding a rule to that file to allow read access to the directory. I’ve not done anything like this before, but my understanding is that the file may only need to have this in it:
/home/KHolloway/Unison/Clients/c/Clare_Computer_Solutions/* r,
But there may be more to it than that. Once the change is in place, restart apparmor and you should be good to go.
ETA: Editing apparmor auditing, looks like you can do it one of two ways. For a quick enable, just run sudo auditctl -e 1. To make it permanent, you would add a command-line parameter to the kernel load line (editing /etc/default/grub to modify the GRUB_CMDLINE_LINUX_DEFAULT value to add audit=1 to it (or change it from audit=0). Once changed, then you would need to run sudo grub2-mkconfig -o /boot/grub2/grub.cfg to rebuild the grub menus.
@hendersj It’s best to use update-bootloader as it maybe systemd-boot in play or others… likewise to add options…
1 Like
It turns out AppArmor is logging, just not where I was looking:
sudo tail -f /var/log/audit/audit.log
type=AVC msg=audit(1780530208.624:2077): apparmor="DENIED" operation="capable" class="cap" profile="wpa_supplicant" pid=2601 comm="wpa_supplicant" capability=2 capname="dac_read_search"
type=AVC msg=audit(1780530208.624:2078): apparmor="DENIED" operation="capable" class="cap" profile="wpa_supplicant" pid=2601 comm="wpa_supplicant" capability=1 capname="dac_override"
I don’t know what “dac_read_search” and “dac_override” are, but once I allowed them (and read access to my certificate files):
KHolloway@Ken-System76:~/Unison/Clients/c/Clare_Computer_Solutions>sudo vi /etc/apparmor.d/local/wpa_supplicant
capability dac_override,
capability dac_read_search,
/home/KHolloway/Unison/Clients/**.key r,
/home/KHolloway/Unison/Clients/**.pem r,
It works now.
I understand the read access to the files, but what is “capability dac_override” and “capability dac_read_search”? Are those “bad”, or is it okay to do this?
Also, this had been working for years, with no changes on my side. Any idea why it broke recently? Did something change in AppArmor (probably about two weeks ago)?
No idea what caused it to break - but glad it’s been resolved. Probably just a tightening of security standards at some point.
The two overrides you’re specifying here are to let the wpa_supplicant process access those capabilities completely, so they (as I understand it) essentially make the last two lines unnecessary. Did you find that they were necessary in order for the specific access to work? (I’m no expert on AppArmor, so I don’t know if they’re necessary; my understanding is that they shouldn’t be because you’ve explicitly granted the process permission to read files in the paths specified.).
I don’t even know what “capabilities” are in this context.
Yes, I had to also allow access to the files. (With either just the capabilities or just the files, it still did not work.)
Interesting, I wasn’t sure if that was necessary or not. We’ve both learned something today. 
“Capabilities” are kernel-level permissions - man capabilities should provide some details. It allows for doing things like enabling promiscuous mode access to network cards (for network analysis with tools like tcpdump and wireshark) when you’re not running those tools as root.