Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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:

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

share|improve this question
1  
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. –  Shane Madden Jan 11 '12 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.)

share|improve this answer
    
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 Apr 16 '12 at 15:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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