The ubuntu docs on OpenVPN have this part in the instructions:

Copy the following files to the client:

  • /etc/openvpn/ca.crt
  • /etc/openvpn/easy-rsa/keys/hostname.crt
  • /etc/openvpn/easy-rsa/keys/hostname.key
  • /etc/openvpn/ta.key

Isn't it possible for a vpn scheme to only require an admin to install the client's public keys in order to give a client access, instead of requiring the sharing of sensitive certs first? Are there other VPNs that do this?


Let's look at a breakdown of all the files, whether they're sensitive, and where they came from.


Publicly disposable, this is the certificate for your VPN's certificate authority. It can be shared with anybody and allows the client to verify the VPN server.


This is a certificate identifying the client. It was signed by the client's private key and then that was signed by the CA's key.


This is the client's private key. In the documentation you're looking at, it was generated on the server for convenience so that the client certificate could be signed by the key there and then signed by the CA key. The private key could be generated and kept on the client without the server ever seeing it, but that would make the process a lot more complex. If you're interested, do some Googling or open another question creating a private CA -- it's a whole other department.


This one is a bit special, so I'll just paste some related I found at http://openvpn.net/index.php/open-source/documentation/howto.html:


The tls-auth directive adds an additional HMAC signature to all SSL/TLS handshake packets for integrity verification. Any UDP packet not bearing the correct HMAC signature can be dropped without further processing. The tls-auth HMAC signature provides an additional level of security above and beyond that provided by SSL/TLS. It can protect against:

  • DoS attacks or port flooding on the OpenVPN UDP port.
  • Port scanning to determine which server UDP ports are in a listening state.
  • Buffer overflow vulnerabilities in the SSL/TLS implementation.
  • SSL/TLS handshake initiations from unauthorized machines (while such handshakes would ultimately fail to authenticate, tls-auth can cut them off at a much earlier point).

Using tls-auth requires that you generate a shared-secret key that is used in addition to the standard RSA certificate/key:

openvpn --genkey --secret ta.key


Yes, it is possible to share everything necessary in the clear except for ta.key if you generate the client's key locally and have a good method of verifying that you used the right keys. The system can be secure without ta.key -- it's just an extra measure to limit outsiders. That said, it's a really good measure.

  • 1
    Wait, wait, "share everything in the clear" - even the client's private key? Most OpenVPN setups I've seen generated the client key on the server, and then passed it to the client through a secure channel (offline, usually). Or am I misunderstanding, and by "generate client's key locally" you mean "locally on the client machine"? – Piskvor left the building Mar 2 '12 at 21:33
  • 2
    @Piskvor Yes, I mean generating the client key on the client machine is possible and then having the client certificate signed on the server without transmitting the client's private key anywhere. This, for example, is common with setting up SSL on Puppet. The client key and cert are generated on the client and then the key hash is verified on the server for signing. – Jeff Ferland Mar 2 '12 at 21:41
  • Aha. Glad that's sorted out, thanks for the clarification :) – Piskvor left the building Mar 2 '12 at 21:45
  • The problem is that cleartext first exchange shouldn't be intercepted, else one does not know it actually is that client, or that server. – ewanm89 Mar 2 '12 at 22:58
  • @ewanm89 Remember that authentication and encryption are different things. We do not need them to be secret and we're ok if they're intercepted. What we need is reliable authentication -- whether that be signed by another trusted key or walking down the hall with a slip of paper that has the key's fingerprint on it. – Jeff Ferland Mar 3 '12 at 6:05

To put it simply: The public key (hostname.crt) is derived, mathematically, from the private key, and it's used to verify that the client actually posesses the correct private key (and is able to decrypt it in case it's protected).

So, you absolutely need to get the private key to the client in a secure way - without this, the public key on the server is somewhat pointless.

As for the others: ca.crt is used by the client to verify that it's indeed connecting to the correct server (and not a MITM), and ta.key is a shared secret for both the client and the server (basically, "something you have").

This is a common problem for all VPN solutions using certificates. You could only use the shared secret (e.g. username+password when using PPTP), but this is 1) usually much less secure as the password isn't very long, and 2) doesn't protect you from MITM attacks.


Yes, it is possible to configure OpenVPN so you only need to install the client's public key and client's cert on the server, and only need to install the server's public key and the server's cert on the client.

Public keys and certificates are not sensitive. They're not confidential: they can be safely shared with the world, if for some reason you wanted to. They do not reveal the private key.

  • Interesting -- so does your answer conflict with the suggested setup in the page I linked to? Does it conflict with @Jeff Ferland's answer? – John Bachir Mar 3 '12 at 18:21
  • 1
    This answer says the same thing as Jeff Ferland's answer. It's just at a higher, conceptual level. Conceptually, each end needs its own private key and at least one end needs the other end's certificate. (In some cases, each end may need the other's certificate.) – David Schwartz Mar 4 '12 at 0:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.