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