The dac_override capability is requested on an access attempt where DAC permission do not allow this access and usually indicate a problem with the permissions.

Please enable full auditing
https://fedoraproject.org/wiki/SELinux/Debugging#Enable_full_auditing
and when reproduced again, check permissions for the file or directory.

Here is the audit result:

type=PROCTITLE msg=audit(06. 03. 2026 09:11:59.168:1308) : proctitle=/usr/libexec/nm-l2tp-service 
type=PATH msg=audit(06. 03. 2026 09:11:59.168:1308) : item=0 name=/home/miha/cert.p12 nametype=UNKNOWN cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(06. 03. 2026 09:11:59.168:1308) : cwd=/ 
type=SYSCALL msg=audit(06. 03. 2026 09:11:59.168:1308) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=AT_FDCWD a1=0x555be3409bc0 a2=O_RDONLY|O_CLOEXEC a3=0x0 items=1 ppid=1 pid=150441 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=nm-l2tp-service exe=/usr/libexec/nm-l2tp-service subj=system_u:system_r:l2tpd_t:s0 key=(null) 
type=AVC msg=audit(06. 03. 2026 09:11:59.168:1308) : avc:  denied  { dac_override } for  pid=150441 comm=nm-l2tp-service capability=dac_override  scontext=system_u:system_r:l2tpd_t:s0 tcontext=system_u:system_r:l2tpd_t:s0 tclass=capability permissive=0 

And here is the cert.p12
-rw-r-----. 1 miha root 2982 feb 12 14:19 cert.p12

Certificate, as shown above, is currently in my home directory. It can be read when using sudo, I assume root can access it.

Is it not expected a system service would use any data from user's homes.

If you have Fedora defaults, root cannot access /home/miha without dac_read_search or dac_override capability and traverse further.

Yep, I have Fedora defaults, then where am I supposed to store the certificate?

Also, as user friendly suggestion, there could be a warning when setting the certificate stored in an unfriendly place.

I am afraid I cannot help you much now.
Is there any recommendation in the package?
Can you start the service as a user service?

There are some standardized places for storing certificates:
~/.pki/nssdb
~/.local/share/pki/ca-certificates-user/
and there are a lot of package-specific ones. This would not help you though with dac_read_search if the service is a system one.

If you could find any shared place, cert_t would be a good first choice for the SELinux type:

f45# sesearch -A -s l2tpd_t -t cert_type -c file -p read
allow l2tpd_t cert_t:file { getattr ioctl lock map open read };

but there will be more options.

Created attachment 2134950 [details]
ausearch output

I believe this is related to NetworkManager and VPN clients' fixes for CVE-2025-9615 :

- https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2324
- https://access.redhat.com/security/cve/CVE-2025-9615
- https://bugzilla.redhat.com/show_bug.cgi?id=2391503

CVE-2025-9615 allows non-admin users to access other user's certificates. But as mentioned above in the Red Hat page "SELinux is shipped out of the box in targeted enforcing mode, which prevents processes from having unwanted permissions and mitigates this attack."

NetworkManager-l2tp 1.20.22 and later has a CVE-2025-9615 fix which verifies file permissions for private VPN connections to prevent unprivileged users from using other user's certs, which is archived using the nm_utils_copy_cert_as_user() function to copy the corresponding certificate file as the user and then store it under the temp location /run/NetworkManager/cert/.

NetworkManager-l2tp CVE-2025-9615 fix is in combination with NetworkManager 1.52.2, 1.54.3 or 1.56.0 and later which provide the other half of the CVE-2025-9615 fix. See:
    https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/2324

NetworkManager-l2tp CVE-2025-9615 fix is based on Íñigo Huguet's NetworkManager-openvpn CVE-2025-9615 fix:
    https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/commit/4b35ef43db806b40600c450c936432b5d04b3f3a

Not all NetworkManager VPN clients have a CVE-2025-9615 fix yet, apart from NetworkManager-openvpn, NetworkManager-strongswan also has the fix, not sure if other VPN clients do.

I attached an output of "ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today", you'll notice /usr/libexec/nm-libnm-helper copies a certificate from the users directory and places it under /run/NetworkManager/cert/

The majority of NetworkManager-l2tp users don't use certificates, so that is the main reason why there aren't a lot more users reporting the issue.

Sorry I'm not sure what the correct way is to proceed with the fix, but it seems the CVE-2025-9615 certificate fix is interfering with SELinux.

Typo in my last comment regarding NetworkManager-l2tp version numbers.

NetworkManager-l2tp-1.52.0 introduced the CVE-2025-9615 fix and is available in Fedora 43 Updates.

The NetworkManager-l2tp-1.20.20-4.fc43 package that shipped with Fedora 43 does not have the CVE-2025-9615 fix.

Miha, are you using NetworkManager-l2tp-1.20.20-4.fc43 or the newer NetworkManager-l2tp-1.52.0-1.fc43 ? The reason I ask is because I don't see "proctitle=/usr/libexec/nm-libnm-helper" nor "name=/run/NetworkManager/cert/" in your SELinux auditing output.

I suggest doing a "dnf update NetworkManager-l2tp" to make sure you have NetworkManager-l2tp-1.52.0-1.fc43.