Auto CRL check

[y0no]

Hello,
I try to revoke a client certificate using the commands shown in the documentation:

docker run --rm -i --volumes-from vpn -e "EASYRSA_BATCH=1" kylemanna/openvpn easyrsa revoke toto
docker run --rm -i --volumes-from vpn kylemanna/openvpn easyrsa gen-crl

The process seems to be ok, but when I try to connect to vpn with my revocated certificate, it works...
The docker-openvpn logs:

Fri Jan 29 23:17:04 2016 172.17.0.1:41187 CRL CHECK OK: CN=blah
Fri Jan 29 23:17:04 2016 172.17.0.1:41187 VERIFY OK: depth=1, CN=blah
Fri Jan 29 23:17:04 2016 172.17.0.1:41187 CRL CHECK OK: CN=toto
Fri Jan 29 23:17:04 2016 172.17.0.1:41187 VERIFY OK: depth=0, CN=toto

Does this reaction normal ?

[kylemanna]

Did you restart the server after you generated the CRL? The ovpn_run script looks for the presence of the CRL and passes the path to openvpn if found. If you created the CRL and never restarted the container, the argument was never passed.

Can you run a ps and see if the crl-verify arugment is passed? If it isn't can you restart your container and confirm that it is?

[1] https://github.com/kylemanna/docker-openvpn/blob/e7d0d4e/bin/ovpn_run#L42-L49

[y0no]

If I restart the server after the CRL generation it work correctly.
But in my VPN server creation script. I have done something like that:

docker run --name $VOL_NAME -v $CONFIG:/etc/openvpn busybox
docker run --volumes-from $VOL_NAME --rm synvpn ovpn_genconfig -u udp://vpn01.synhack.fr:$PORT -t
docker run --volumes-from $VOL_NAME --rm -i -e "EASYRSA_REQ_CN=synhack" -e "EASYRSA_BATCH=1" synvpn ovpn_initpki nopass <<< $'\n'
docker run --volumes-from $VOL_NAME --rm kylemanna/openvpn easyrsa gen-crl
docker run --name $CTR_NAME --volumes-from $VOL_NAME -d -p $PORT:1194/udp --cap-add=NET_ADMIN synvpn

I don't understand why it don't automatically stop to accept connection from revoked certificate after revoke command has been fired without restarting the server.

[y0no]

The problem seems to come from the hardlink between /etc/openvpn/crl.pem and /etc/openvpn/pki/crl.pem. When I check the revoked certificates with "openssl crl" command. I have revoked certificates with /etc/openvpn/pki/crl.pem but not with /etc/openvpn/crl.pem.

Did you know what can cause this issue ?

[kylemanna]

That's interesting. That would explain the problem you have. I apparently didn't do enough testing with new revocations.

Sounds like the file is being replaced by openssl breaking the hardlink? Could you verify this by running ls -li to see the inode number? I bet initially they are the same, but when you revoke another certificate they are different and hence not updated.

The solution may be a wrapper for the easyrsa revocation generation to copy the file to the correct location with the correct permissions instead of using the hardlink.

[y0no]

Effectively the inode number seems to change.
Currently my script copy the file in /etc/openvpn after each revocation, But you are right, it will be better to modify easyrsa to do that.

[fabn]

@kylemanna I'm encountering the same issue. Any fix for this?

Why are you using ln in this line? Wouldn't be much simpler to change line 49 to something like

ARGS+=("--crl-verify" "$OPENVPN/pki/crl.pem")

Is there any drawback in doing that?

Also according to this thread client documentation is outdated.

[fabn]

Why are you using ln in this line

Ok, I think this is needed because /etc/openvpn/pki/ has 600 permissions and openvpn daemon drops root privileges before reading that file. So a solution might be to replace ln with cp, this however will require users to restart openvpn image for each crl change.

Thoughts?

[kylemanna]

Yes, this is a problem. Could try a hardlink to that file that the openvpn user can read?

[johnreutersward]

I'm also having trouble with revoked client certificates even after restarting the container.

After running revoke and gen-crl I see that the certificate is listed as REVOKED when running ovpn_listclients.

However, it seems that restarting the docker container does not seem to have any effect. I am still able to connect with a revoked certificate.

[kylemanna]

@rojters do you see --crl-verify /etc/openvpn/crl.pem passed to the openvpn binary using something ps waux?

[johnreutersward]

@kylemanna Yes, that appears to be the case:

Running docker exec CONTAINER ps waux shows the following output:

PID   USER     TIME   COMMAND
    1 nobody     0:03 openvpn --config /etc/openvpn/openvpn.conf --client-config-dir /etc/openvpn/ccd --crl-verify /etc/openvpn/crl.pem

[kylemanna]

Hmm. This is something that should be unit tested so that it doesn't happen.

Can someone write up the exact steps to reproduce on the lastest docker image and I'll take a look at it.