OpenVPN connection blocked by SeLinux

Ask Fedora
,
1

I don’ t get this what if ~ is already /home/j?

SELinux is preventing openvpn from open access on the file /home/j/.cert/client.crt.

*****  Plugin openvpn (47.5 confidence) suggests   ***************************

If you want to mv client.crt to standard location so that openvpn can have open access
Then you must move the cert file to the ~/.cert directory
Do
# mv /home/j/.cert/client.crt ~/.cert
# restorecon -R -v ~/.cert


*****  Plugin openvpn (47.5 confidence) suggests   ***************************

If you want to modify the label on client.crt so that openvpn can have open access on it
Then you must fix the labels.
Do
# semanage fcontext -a -t home_cert_t /home/j/.cert/client.crt
# restorecon -R -v /home/j/.cert/client.crt


*****  Plugin catchall (6.38 confidence) suggests   **************************

If you believe that openvpn should be allowed open access on the client.crt file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'openvpn' --raw | audit2allow -M my-openvpn
# semodule -X 300 -i my-openvpn.pp

Additional Information:
Source Context                system_u:system_r:openvpn_t:s0
Target Context                unconfined_u:object_r:user_home_t:s0
Target Objects                /home/j/.cert/client.crt [ file ]
Source                        openvpn
Source Path                   openvpn
Port                          <Unknown>
Host                          rhnmnb19572
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-44.2-1.fc44.noarch
Local Policy RPM              selinux-policy-targeted-44.2-1.fc44.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     rhnmnb19572
Platform                      Linux rhnmnb19572 7.0.12-200.fc44.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Tue Jun  9 19:05:29 UTC 2026
                              x86_64
Alert Count                   4
First Seen                    2026-06-14 14:18:19 CEST
Last Seen                     2026-06-14 14:22:33 CEST
Local ID                      73b31e85-a342-43ca-9eb7-b706438b873f

Raw Audit Messages
type=AVC msg=audit(1781439753.377:358): avc:  denied  { open } for  pid=7482 comm="openvpn" path="/home/j/.cert/client.crt" dev="dm-0" ino=5385913 scontext=system_u:system_r:openvpn_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0


Hash: openvpn,openvpn_t,user_home_t,file,open
2

Yeah, that first suggestion doesn’t look sensible.

The second one (fixing the labels) looks more likely. The AVC message suggests that your ~/.cert has got labelled as user_home_t when it should be home_cert_t (per the policy).

What do you get from this?

ls -lZ /home/j/.cert/client.crt

(Edited the above with @computersavvy 's suggestion, which is better.)

That should show the label - if it’s user_home_t then it needs to be fixed.

4

The file /home/j/.cert/client.crt is a file that has been created under the home directory of user j (/home/j) , and appears to have been created by openvpn. However, the user under which open vpn runs is restricted from access to that file by the selinux context that was assigned when the file was created.

The message shows which context to assign the file so openvpn is allowed access in its current location.

If you want to modify the label on client.crt so that openvpn can have open access on it 
Then you must fix the labels.
Do
# semanage fcontext -a -t home_cert_t /home/j/.cert/client.crt
# restorecon -R -v /home/j/.cert/client.crt

You can see the current context of that file with ls -lZ /home/j/.cert/client.crt

The preferred method is this one

If you want to mv client.crt to standard location so that openvpn can have open access
Then you must move the cert file to the ~/.cert directory
Do
# mv /home/j/.cert/client.crt ~/.cert
# restorecon -R -v ~/.cert

It would appear that user j may have been the user that initially launched openvpn and the message appeared when a different user tried using it. OR that the wrong context was assigned when the file was created (which would be the bug to be reported).