OpenVPN: self-signed certificate in chain

opensslopenvpn

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

…

(blink!)

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."

Best Answer

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.)

Related Topic