Linux – SELinux not allowing read files on ~/.cert

I'm new to Fedora 23 and SELinux. I use an OpenVPN client through NetworkManager. I stored all the files I needed OpenVPN to access (certificate, CA and private key) inside ~/.cert and ran updatecon -R -v ~/.cert. However, I'm still getting AVC errors from SELinux, who won't let OpenVPN access such files. This the relevant portion of the output of grep AVC /var/log/audit/audit.log | less:

type=AVC msg=audit(1457179403.296:364): avc:  denied  { open } for  pid=2608 comm="nm-openvpn-serv" path="/home/ggoncalves/.cert/ggoncalves.key" dev="dm-2" ino=2888752 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c50,c545 tclass=file permissive=0
type=AVC msg=audit(1457179403.296:365): avc:  denied  { open } for  pid=2608 comm="nm-openvpn-serv" path="/home/ggoncalves/.cert/ggoncalves.key" dev="dm-2" ino=2888752 scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c50,c545 tclass=file permissive=0
type=AVC msg=audit(1457179403.330:366): avc:  denied  { read } for  pid=2611 comm="openvpn" name="lastline-ca.crt" dev="dm-2" ino=2888749 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c50,c545 tclass=file permissive=0
type=AVC msg=audit(1457179403.332:367): avc:  denied  { read } for  pid=2611 comm="openvpn" name="ggoncalves.crt" dev="dm-2" ino=2888751 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c50,c545 tclass=file permissive=0
type=AVC msg=audit(1457179403.332:368): avc:  denied  { read } for  pid=2611 comm="openvpn" name="ggoncalves.key" dev="dm-2" ino=2888752 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c50,c545 tclass=file permissive=0

Since I've only been using SELinux for a few days, I have no clue where to start looking for this. Any hints?

Edit: It seems to me that the problem is in the svirt_sandbox_file_t label. I believe those files should be labelled home_cert_t.

Edit 2: In fact, my whole home directory has been labeled svirt_sandbox_file_t for some reason. Is this a feature or a bug of Docker policies?

Update

Alright, this took a while. Let me further describe the issue, in case someone ends up going through the same. Turns out the svirt_sandbox_file_t had been attributed by Docker when I mounted my home directory as a volume with the :Z flag (as described here). Docker then recursively applied that label to my entire home dir, and somehow neither reconfiguring the FS labels nor applying restorecon worked.

To restore my home to the original permissions, I rsync'd it to a temporary folder, deleted everything in it and rsync'd back. Not the brightest idea, but it worked.