3

This was moved from NetworkEngineering.

I used this DigitalOcean guide (hereafter "guide") to set up an OpenVPN service (v2.3.10, OpenSSL 1.0.2g) several months ago. It's worked flawlessly, and it's faster than our old VPN appliance. I'm at a point now where I need to revoke a certificate. I followed the steps at step 14 in the guide, and on this page without any luck.

I added crl-verify $SomeSuchDir/crl.pem (where $SomeSuchDir is any of the paths '/etc/openvpn', '/root/openvpn-ca/keys', and null (as stated in the guide)) to the config file, restarted the service, and none of the certificates work, valid or revoked alike. With the crl-verify crl.pem option enabled, I get this error

"TLS_ERROR: BIO read tls_read_plaintext error: error:14089086:SSL routines:ssl3_get_client_certificate:certificate verify failed"

when a valid or revoked certificate tries to connect. When I comment out the option and restart the service, I can still connect with an apparently revoked certificate. The "index.txt" file has an 'R' and additional field present for the revoked cert and I get the "error 23" message when I run revoke-full bad-cert script.

I had a look in the revoke-full script, vars variable file, and openssl-1.0.0.cnf file, and it looks like everything is where it's supposed to be. Has anyone else had a problem generating a CRL for OpenVPN?

UPDATE:

After moving this from NetworkEngineering, I poked around in the log file and found CRL: cannot read CRL from file $SomeSuchDir/crl.pem. The file was at least world readable. I came across this post, where the author had similar problems. His solution was to comment out the two lines that run the OpenVPN service as nobody:nogroup. Although my crl.pem file was world readable, the ancestor directories have to be at least "r-x" for nobody:nogroup. My files were all inside /root, so that was inaccessible to nobody:nogroup.

I created /REV and stuck crl.pem inside it, and made nobody:nogroup the owner. I changed the config option to crl-verify /REV/crl.pem and restarted the service. The revoked certs seem to be disallowed and the valid certs are allowed.

I went through another round of connecting with another cert-to-be-revoked. I did ./revoke-full cert-to-be-revoked, got the appropriate "error 23..." and "Database updated" messages, copied $KEY_DIR/crl.pem to /REV/, telnetted to the management interface, executed kill cert-to-be-revoked, and the client couldn't reconnect. I verified the revoked certificate and corresponding serial number was in "Revoked Certificates:" with openssl crl -in crl.pem -text.

So now the question is, is it safe to run the OpenVPN service(s) as root:root instead of nobody:nogroup?

2
  • 2
    Obviously it's not safe. Just find a more appropriate directory for your certs and fix the permissions. Dec 28, 2017 at 4:55
  • Check selinux or set permissive TEMPORARILY Dec 28, 2017 at 12:52

1 Answer 1

1

I would not run openvpn as root:root that would be a major security issue.

add a new user in a shell openvpn with a group openvpn change the ownership of the config, and the certificates to be openvpn

chown -R openvpn:openvpn /etc/openvpn/*

Assuming you have a login of your own, and if you want to be able to update the config or any files you can add your login to group openvpn, then use the group permissions to enable access to the files you want to write/read to/from.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .