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."
openssl s_client -connect host:port -showcerts
, and compare the thumbprint of the received cert withopenssl x509 -noout -text -in ca.crt
.