Files inside private shares are owned by user:root, which means VPN keys and the like can't be used by network-manager

I'm on an Ubuntu system, with uname -a producing:
Linux desktop 4.4.0-36-generic #55-Ubuntu SMP Thu Aug 11 18:01:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I've moved over my keys (VPN, PGP, SSH, etc.) to a private folder, but I can't control the permissions of them -- they're all forcibly stuck at k2trf:root 0700! This means they can't be used by anything else not running as me, like if I wanted the system to be able to read the cert file for my VPN.

I can't alter the permissions in any way -- they just rebound back to this value, which is very unhelpful. I get the idea as a default, and I do like it, but why on earth can users not change it after the fact? Under a normal circumstance, I suppose the answer could be to run the program/application as said user, but I can't reasonably do that for network-manager, which runs as root at system start (/usr/sbin/NetworkManager --no-daemon).

Is this a bug, or just bad design? Because if there's no way around this, I cannot use keybase to store my various keys and certs, which is really what I saw in keybase -- my certs under my control, but still encrypted and syncing (without a cloud server).

For reference, I know its a permission issue thanks to /var/log/syslog printing:
Aug 12 13:58:24 desktop nm-openvpn[5956]: Options error: --ca fails with '/keybase/private/k2trf/[PATH TO FILE].crt': Permission denied Aug 12 13:58:24 desktop nm-openvpn[5956]: Options error: Please correct these errors. Aug 12 13:58:24 desktop nm-openvpn[5956]: Use --help for more information.

Following the permission error, it was obvious when I saw
-rwx------ 1 k2trf root 1684 May 24 23:25 [FILE].crt

I can modify the user permissions, but nothing else. Literally, all I need is to give the group (root) read permissions, and I'd have my userspace working again; I just can't get the permissions to change and stick.

Start by reproducing the permission behavior on Ubuntu using the private path and the /usr/sbin/NetworkManager scenario, then inspect the related syslog permission error. Determine where private-share ownership and mode handling is defined; done means establishing whether group/root read access can persist for these files and recording or implementing the resulting behavior.