The plain answer is it does not work because you've got it all wrong.
Your basic misconception seems to lie in the idea that OpenVPN and the Certificate Authority do have a communication channel so OpenVPN would automagically know which certificates you want to allow. This is not the case. OpenVPN and the Certificate Authority are completely separate entities (even if they both reside on the same host) and do not have any communication whatsoever between each other.
The CA "signs" certification requests (basically public keys bundled with identification information like the host name) by encrypting a hash of the certification request with its own private key. What OpenVPN does is checking whether a) it can decrypt the hash using the public key of the CA (which it has, typically residing in a ca.crt file somewhere) and checking if the hash is correct for the given certificate. It does not require nor use any "live" connections to the CA for any of this.
You cannot revoke a certificate by deleting it from the CA's directory (note that if you have deleted the client certificate and it was your only copy, openssl ca
would not allow you revoke it any more) or changing the index.txt (this file is just an indication for openssl ca
about the state of the available certificates). What you need to do instead is
- run
openssl ca -revoke <certificate file>
to revoke the certificate in the internal OpenSSL CA database (basically adding the revocation information in the index.txt
)
- create a certificate revocation list using
openssl ca -gencrl -out ca.crl
- copy this revocation list to the OpenVPN revocation list file (see the
crl-verify
directive in the OpenVPN config file)
- see OpenVPN deny the connection on the next certificate check
If you are using the easy-rsa
shell wrapper script set for OpenSSL CA, see the OpenVPN section on certificate revocation for a more detailed documentation on how to achieve the above using the easy-rsa scripts. The basic procedure is
# cd into the easy-rsa directory
cd <somewhere>/easy-rsa
# load your CA-related variables into the shell environment from the ./vars file
. ./vars
# run the revoke script for <clientcert.pem>
./revoke-full clientcert
you would find the crl.pem in the $KEY_DIR
directory as defined in your ./vars
file.
How are you planning on doing client authentication? Are you planning on doing cert-based client authentication, or something else?
I wonder if I can use my existing SSL certificate for that purpose? Do I have any advantages doing that?
Yes you probably could get away with re-using a certificate, so long as your cert subject value matches the name of your OpenVPN server.
This is almost certainly a bad idea though. There are little or no advantages to do it. You will probably make things more difficult and confusing for yourself if you try and you aren't very well versed in how PKI works.
In any case, for your first VPN server I strongly suggest following the guide as it is written before you try doing anything fancy with external CAs, or 3rd party certificates. OpenVPN is extremely flexible, but it is best to stick with the standard method to start.
Do OpenVPN clients use well known root certificates to check server's certificate or they do not employ this infrastructure and self-signed certificate will work fine?
Generally when setting open OpenVPN clients you give the client the CA cert in addition the suggested configuration.
Best Answer
You can use
client-config-dir
to specify the Common Names which you wish to allow. The name of the file should be the CN of the certificate you wish to allow, and then you write averify-cn
script (The one we have at work was probably written by the admin who setup our OpenVPN, but I'm sure there's standard ones out there) that checks that the CN in the presented certificate equals a file in the CCD directory. Tell OpenVPN to use it with thetls-verify
option and setscript-security
to 2 so that theverify-cn
script can be run, and you're away.However all this doesn't negate the need for a CRL. Without a CRL you won't be able to revoke a specific issue of a client's certificate. For instance if their existing certificate was compromised or lost and they were issued a new certificate with the same Distinguished Name details.
Arguably a CRL is also slightly more secure than removing a client's CCD configuration because the SSL checking is performed further up the chain.