Ok, I'll explain what I did... and at the end is the queston. THank you!

To set up my VPN I installed OpenVPN in server and client machines. On server I configured the cert Authority in the file /etc/openvpn/easy-rsa/vars editing this lines:

export KEY_CITY=”Madrid”
export KEY_ORG=”My Organization”
export KEY_EMAIL=”[email protected]

then i generated the cert:

cd /etc/openvpn/easy-rsa/ ln -s openssl-1.0.0.cnf openssl.cnf source vars ./clean-all ./build-ca

Created the cerver certs:

./build-key-server myServer

Diffie Hellman parameters to server


Copyed certs and keys /etc/openvpn

cd keys/ cp myServer.crt myServer.key ca.crt dh1024.pem /etc/openvpn/

Created client Certs

cd /etc/openvpn/easy-rsa/ source vars ./build-key client1

Copied this certs to client machine and erased them from server:




Edited /etc/openvpn/server.conf to my files names

ca ca.crt
cert myServer.crt
key myServer.key
dh dh1024.pem

/etc/init.d/openvpn restart

Verified that tun0 is there

ifconfig tun0

Enabled ip_forward parameter on /etc/sysctl.conf so packages may flow


Also enabled virtual network masking so client may access all remote machines

iptables -t nat -A POSTROUTING -s -o eth0 -j MASQUERADE

and saved the ip tables conf so they dont desappear in a reboot

Save conf into file

sudo sh -c “iptables-save > /etc/iptables.rules”

Edit /etc/network/interfaces adding the interface (eth0 in this case)

pre-up iptables-restore < /etc/iptables.rules

Getting the following server.conf

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
ifconfig-pool-persist ipp.txt
keepalive 10 120
status openvpn-status.log

In the client i installed OpenVPN and edited the client.conf file which is in /etc/openvpn with the certs: ca.cert, client1.key, client1.conf getting the following client.conf file:

dev tun
proto udp
remote xxx.xxx.xxx.xxx 1194
resolv-retry infinite
ca ca.crt
cert client1.crt
key client1.key
ns-cert-type server
verb 3

then restarted:

/etc/init.d/openvpn restart

And when i want to verify that the interface tun0 is there with ifconfig tun0, there is not.

So I checked my log for errors, in the client machine and there is this error:

VERIFY ERROR: depth=0, error=unable to get local issuer certificate: /C=Es/ST=M/L=Madrid/O=xxx/OU=xxx/CN=myServer/name=xxx/[email protected]
TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
user openvpn[7984]: TLS Error: TLS object -> incoming plaintext read error
user openvpn[7984]: TLS Error: TLS handshake failed

and this is the error int the servers log

xxx.xxx.xxx.xxx:59439 SIGUSR1[soft,tls-error] received, client-instance restarting
MULTI: multi_create_instance called
xxx.xxx.xxx.xxx:59485 Re-using SSL/TLS context
xxx.xxx.xxx.xxx:59485 LZO compression initialized
xxx.xxx.xxx.xxx:59485 Control Channel MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
xxx.xxx.xxx.xxx:59485 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:135 ET:0 EL:0 AF:3/1 ]
xxx.xxx.xxx.xxx:59485 Local Options hash (VER=V4): '530fdded'
xxx.xxx.xxx.xxx:59485 Expected Remote Options hash (VER=V4): '41690919'
xxx.xxx.xxx.xxx:59485 TLS: Initial packet from [AF_INET]xxx.xxx.xxx.xxx:59485, sid=0349f4d6 657535c9
xxx.xxx.xxx.xxx:59440 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
xxx.xxx.xxx.xxx:59440 TLS Error: TLS handshake failed
xxx.xxx.xxx.xxx:59440 SIGUSR1[soft,tls-error] received, client-instance restarting

I've created the keys again, and added the full path of the certs in the client.conf file but it still doesn't work. Also tryed with all my firewalls disabled and still cant conect to my server because of that error.

Another important thing is that my server is an ubuntu 12.04 and client CentOS 6.3

I can see that i find my server but still the connection isn't completed...

What should I do??

If any more config files are needed, tell me to show you

  • What's the server configuration?
    – cjc
    Jan 15, 2013 at 21:20
  • ok here it is. I added it to the question
    – AAlvz
    Jan 15, 2013 at 21:38
  • Your posted server configuration appears to have the key and cert pointing to the client key/cert.
    – cjc
    Jan 15, 2013 at 21:55
  • Sorry. Finger error.. Let me correct..
    – AAlvz
    Jan 15, 2013 at 21:59
  • Don't delete the client keys off the server.
    – Jim G.
    Jan 15, 2013 at 22:01

2 Answers 2


Your error message indicates that the client doesn't like the certificate presented by the server for whatever reason. Send a copy of server.crt to the client, then run:

openssl verify -purpose any -CAfile ca.crt server.crt

If it's OK, you should get something that looks like server.crt: OK

Basically, you want to check that the server.crt is properly signed by the ca.crt file on the client. You can play with the options to see what a failure looks like by leaving out the -CAfile ca.crt. In this case (or if the ca.crt did not sign the server.crt) you will get some message like:

error 20 at 0 depth lookup:unable to get local issuer certificate

If this is the case, go over your certificate generation process.

  • Thank you very much. Very usefull answer... I did get the message you say error 20 at 0 depth lookup:unable to get local issuer certificateso i'm going to create the certs again.. What is the best method to create them? Is it ok with RSA scripts? .. or what can you recommend me? ..
    – AAlvz
    Jan 16, 2013 at 0:52
  • And another thought that is bothering me from the beggining... is it ok to create the client certs in the servers and then send them to the client? or should I create the client certs in the client machine? does it matter??
    – AAlvz
    Jan 16, 2013 at 0:58
  • The easy-RSA scripts should be fine. You can run openssl directly, but that can be tricky. For your second question, it depends on your security policy. If you control both end points and the transit (i.e., using ssh/scp), then I would just create everything on the server and send the client files over. If you have a stricter situation, you can have the client generate a proper certificate signing request, send that to the server, generate a certificate off of it, and send the cert to the client. In this case, the private key doesn't leave the client. Might be overkill, though.
    – cjc
    Jan 16, 2013 at 3:49
  • Thank you a lot! ..very useful.. still having troubles =S .. but with this I'm closer..
    – AAlvz
    Jan 16, 2013 at 17:35

I had this issue too. The problem was that I was using the ca.crt that easyrsa generated. This is wrong. Use the cacert.pem in /etc/ssl/misc/demoCA/ instead.

You must log in to answer this question.

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