I am trying very-unsuccessfully to use TunnelBlick (an OS/X OpenVPN 2.2.1 client that is known-good) to connect using certificates. Here is the (sanitized) error message I receive:

2012-01-11 11:18:26 TLS: Initial packet from **.**.**.**:1194, sid=17a4a801 5012e004
2012-01-11 11:18:26 VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: /C=US/ST=**/L=**/O=**/CN=**/emailAddress=**
2012-01-11 11:18:26 TLS_ERROR: BIO read tls_read_plaintext error: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
2012-01-11 11:18:26 TLS Error: TLS object -> incoming plaintext read error
2012-01-11 11:18:26 TLS Error: TLS handshake failed
2012-01-11 11:18:26 TCP/UDP: Closing socket

Now, here's the rub. I generated a CSR myself to request this certificate, using the ca.crt file provided to me by the other side (in fact, they did it twice just to make sure).

The relevant entries in the client configuration are:

ca   ca.crt
cert my.crt
key  my.key

and, furthermore... I can verify the keys in this way:

openssl verify -CAfile ca.crt my.crt 
my.crt: OK

Okay, so now I am thoroughly mystified and stumped. At this point, I know that the CSR and the key were generated using the proper CSR. In fact, here is the very command that did it:

openssl req -newkey rsa:2048 -new -out my.csr -keyout my.key

I also knew to do this:

openssl x509 -subject -issuer -noout -in ca.crt



Did I just find it?

The output of that command looks like this: (edited somewhat)

subject= /C=US/ST=VA/L=**/O=**/CN=** CA/emailAddress=**
issuer= (the same)

whereas in the error message from OpenVPN, the ST= is not exactly the same:

VERIFY ERROR: depth=1, error=self signed certificate in certificate chain: /C=US/ST=Virginia/L=**/O=**/CN=**/emailAddress=**

"VA" is not exactly equal to "Virginia."

  • 2
    Try an openssl s_client -connect host:port -showcerts, and compare the thumbprint of the received cert with openssl x509 -noout -text -in ca.crt. Commented Jan 11, 2012 at 20:43

1 Answer 1


Just to bring full-closure to this thread: that WAS indeed the problem. The "ca.crt" that I had received ("Virginia") WAS NOT in fact the one that my colleague was using ("VA"), and neither one of us noticed at the time.

So... basically (and purely in layman's terms) VPN was trying to take a walk up the chain of authority looking for the ca.crt that it expected to find, but it never did (because it was not there).

And, this is one of those wonderful messages that crypto systems are so well-known for: entirely accurate, and yet, completely mysterious to the uninitiated. (And, to be fair, crypto systems don't like to divulge information about anything, as they presume the person they're talking to is surely evil Eve, not nice Alice or Bob.)

  • To be fair, I'm not convinced this has anything to do with the CA chain and more to do with the fact that it was a different CA in the first place, and thus automatically untrusted. OpenSSL doesn't have to take much of a walk. Maybe that's what you meant though.
    – gparent
    Commented Apr 16, 2012 at 15:15

You must log in to answer this question.

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