CApath with multiple client certs
I love this toolset; definitely value-add for the community!
I am using OpenSSL to run through a sizable number of web server
connections (~500), and tell me which certs are getting ready to expire. My
utility has worked for a while (a couple years?) on 1.0.0 Beta3, and I
recently upgraded to 1.0.0.n. So far, so good... no problems with the
upgrade.
Now I want to extend my usage of OpenSSL, to handle client-side
certificates, because my current utility throws an error on web servers
that require a client side certificate. It seems to work (at least some)
regardless, because openssl s_client shows the server side certificate
before having to provide the client side. But I want to get rid of all the
errors, and ensure I'm getting all server side certs.
In my lab, I've successfully been able to do manual testing, using the
following command from a client:
-- openssl s_client -nowait -connect 192.168.1.145:443 -cert
.\CA\user\usercert.CRT -key .\CA\user\userkey.KEY
And if I dumped both the CRT and KEY into a single PEM file, I could
connect like this:
-- openssl s_client -nowait -connect 192.168.1.145:443 -cert
.\CA\user\combined.PEM
[Note: If you're probably wondering what the '-nowait' option is. My
utility runs on Windows. Since the distributed version (beta3 and .n) would
often hang on the Windows connection, I added a '-nowait' option into the
source and re-compiled the Windows version. Real easy, I'll attach the diff
to the bottom in case anyone is interested in the change to s_client.]
So far I know that when I provide the exact file to use on the command
line, it connects fine. Now my challenge...
For so many servers, I'd like a flexible openssl call that can use a
directory of client certificates/keys, in order to avoid having to specify
the cert for each connection command. That lead me towards the -CApath
parameter. I believe the 'mklink' option on Win2003 or the
CreateSymbolicLink function on Windows 2008 should be able to replace the
'ln -s' code for c_rehash. But I can't get it to work. I always get an ssl
handshake failure. Sample failed output below.
Maybe I'm not creating the base PEM file correctly before hashing the file
to use the CApath? I've tried using a hash file for the CA cert, and one
for the combined.PEM (user cert and user key in same file). And I've tried
using a hash file with all three in one. I must be doing something
obviously wrong. ;(
I would appreciate some direction from the SSL gurus.
Error snapshot follows:
===
Loading 'screen' into random state - done
CONNECTED(00AC)
depth=1 /C=US/ST=Illinois/L=Quincy/O=Leverage
Discovery/OU=Administration/CN=CA
VERIFIER/emailAddress=supp...@test.netmhtml:{0A5176EE-A535-4161-97E6-387F35505019}mid://1174/!x-usc:mailto:VERIFIER/emailAddress=supp...@test.net
verify return:1
depth=0 /C=US/ST=Illinois/O=Leverage
Discovery/OU=Administration/CN=192.168.1.145/emailAddress=supp...@test.netmhtml:{0A5176EE-A535-4161-97E6-387F35505019}mid://1174/!x-usc:mailto:Discovery/OU=Administration/CN=192.168.1.145/emailAddress=supp...@test.net
verify return:1
7192:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure:s3_pkt.c:1160:SSL alert number 40
7192:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:184:
---
Certificate chain
0 s:/C=US/ST=Illinois/O=Leverage
Discovery/OU=Administration/CN=192.168.1.145/emailAddress=supp...@test.netmhtml:{0A5176EE-A535-4161-97E6-387F35505019}mid://1174/!x-usc:mailto:Discovery/OU=Administration/CN=192.168.1.145/emailAddress=supp...@test.net
i:/C=US/ST=Illinois/L=Quincy/O=Leverage Discovery/OU=Administration/CN=CA
VERIFIER/emailAddress=supp...@test.netmhtml:{0A5176EE-A535-4161-97E6-387F35505019}mid://1174/!x-usc:mailto:VERIFIER/emailAddress=supp...@test.net
1 s:/C=US/ST=Illinois/L=Quincy/O=Leverage Discovery/OU=Administration/CN=CA
VERIFIER/emailAddress=supp...@test.netmhtml:{0A5176EE-A535-4161-97E6-387F35505019}mid://1174/!x-usc:mailto:VERIFIER/emailAddress=supp...@test.net
i:/C=US/ST=Illinois/L=Quincy/O=Leverage Discovery/OU=Administration/CN=CA
VERIFIER/emailAddress=supp...@test.netmhtml:{0A5176EE-A535-4161-97E6-387F35505019}mid://1174/!x-usc:mailto:VERIFIER/emailAddress=supp...@test.net
---
Server certificate
-BEGIN CERTIFICATE-
MIIDVTCCAv+gAwIBAgIJAItDpW8cTCDAMA0GCSqGSIb3DQEBBQUAMIGjMQswCQYD
VQQGEwJVUzERMA8GA1UECBMISWxsaW5vaXMxDzANBgNVBAcTBlF1aW5jeTEbMBkG
A1UEChMSTGV2ZXJhZ2UgRGlzY292ZXJ5MRcwFQYDVQQLEw5BZG1pbmlzdHJhdGlv
bjEUMBIGA1UEAxMLQ0EgVkVSSUZJRVIxJDAiBgkqhkiG9w0BCQEWFXN1cHBvcnRA
Z2FyZXgubmV0LmNvbTAeFw0xMjAyMDMxOTI5MjBaFw0xMzAyMDIxOTI5MjBaMIGU
MQswCQYDVQQGEwJVUzERMA8GA1UECBMISWxsaW5vaXMxGzAZBgNVBAoTEkxldmVy
YWdlIERpc2NvdmVyeTEXMBUGA1UECxMOQWRtaW5pc3RyYXRpb24xFjAUBgNVBAMT
DTE5Mi4xNjguMS4xNDUxJDAiBgkqhkiG9w0BCQEWFXN1cHBvcnRAZ2FyZXgubmV0
LmNvbTBcMA0GCSqGSIb3DQEBAQUAA0sAMEgCQQDPCxK0zbev3sHS4GN1uKqJZ4sV
gSuZX/BCdwiKA4h8icyU3fI47+emhl+Z6fivOrv7/Hce+kli2vOyQ/YK8qnLAgMB
RE: CApath with multiple client certs
From: owner-openssl-us...@openssl.org On Behalf Of Chris Satterthwaite Sent: Friday, 03 February, 2012 15:55 I am using OpenSSL to run through a sizable number of web server connections (~500), and tell me which certs are getting ready to expire. My utility has worked for a while (a couple years?) on 1.0.0 Beta3, and I recently upgraded to 1.0.0.n. snip Aside: 1.0.0 is only up to g. Are you a Time Lord? Now I want to extend my usage of OpenSSL, to handle client-side certificates, because my current utility throws an error on web servers that require a client side certificate. It seems to work (at least some) regardless, because openssl s_client shows the server side certificate before having to provide the client side. But I want to get rid of all the errors, and ensure I'm getting all server side certs. It's actually 'without' not 'before', but same result. In my lab, I've successfully been able to do manual testing, using [-cert and -key, or -cert with combined] [Note: If you're probably wondering what the '-nowait' option is. My utility runs on Windows. Since the distributed version (beta3 and .n) would often hang on the Windows connection, I added a '-nowait' option into the source and re-compiled snip I doubt this is Windows specific. Your command line doesn't show any redirection of input, so if s_client successfully connects it waits for user input to be sent to the server and/or server output to be displayed to the user. Redirect NUL: (actually any filename *beginning* with NUL works, but that's a kludge) or an actual empty file. For so many servers, I'd like a flexible openssl call that can use a directory of client certificates/keys, in order to avoid having to specify the cert for each connection command. That lead me towards the -CApath parameter. I believe the 'mklink' option on Win2003 or the CreateSymbolicLink function on Windows 2008 should be able to replace the 'ln -s' code for c_rehash. But I can't get it to work. I always get an ssl handshake failure. Sample failed output below. snip rest You're looking in entirely the wrong place. Even if symlinks work on Windows and I'm not sure about that, CApath and/or CAfile supply CA certs to use to verify the *server* (in general the peer, which for s_client is the server), *not* prove the client, and no key(s) at all (which is necessary for client to prove). I believe, but haven't tracked down exactly, the default truststore (CApath and/or CAfile) is used to *add* chain certs for the client cert if needed, but it cannot be used to supply the client cert (and key) itself. In general if you want to interactively select client cert+key, you need to set _client_cert_cb (callback) or _client_cert_engine. s_client.c currently has the latter, if you write such an engine; or you can modify s_client.c to include and use a callback you write. Or you could write a custom app which just SSL_connect's and displays the server cert (or only server cert notAfter if that's all you want) and doesn't try to do the many other things s_client does. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: CApath with multiple client certs
Hi Dave, Thanks for your ideas and response. Especially the explanation of CApath; very informative. You're right, I'm on version 'g' not 'n'. I'd say it was a typo, but I really thought I was on 'n'. ;) -Chris On Fri, Feb 3, 2012 at 4:48 PM, Dave Thompson dthomp...@prinpay.com wrote: From: owner-openssl-us...@openssl.org On Behalf Of Chris Satterthwaite Sent: Friday, 03 February, 2012 15:55 I am using OpenSSL to run through a sizable number of web server connections (~500), and tell me which certs are getting ready to expire. My utility has worked for a while (a couple years?) on 1.0.0 Beta3, and I recently upgraded to 1.0.0.n. snip Aside: 1.0.0 is only up to g. Are you a Time Lord? Now I want to extend my usage of OpenSSL, to handle client-side certificates, because my current utility throws an error on web servers that require a client side certificate. It seems to work (at least some) regardless, because openssl s_client shows the server side certificate before having to provide the client side. But I want to get rid of all the errors, and ensure I'm getting all server side certs. It's actually 'without' not 'before', but same result. In my lab, I've successfully been able to do manual testing, using [-cert and -key, or -cert with combined] [Note: If you're probably wondering what the '-nowait' option is. My utility runs on Windows. Since the distributed version (beta3 and .n) would often hang on the Windows connection, I added a '-nowait' option into the source and re-compiled snip I doubt this is Windows specific. Your command line doesn't show any redirection of input, so if s_client successfully connects it waits for user input to be sent to the server and/or server output to be displayed to the user. Redirect NUL: (actually any filename *beginning* with NUL works, but that's a kludge) or an actual empty file. For so many servers, I'd like a flexible openssl call that can use a directory of client certificates/keys, in order to avoid having to specify the cert for each connection command. That lead me towards the -CApath parameter. I believe the 'mklink' option on Win2003 or the CreateSymbolicLink function on Windows 2008 should be able to replace the 'ln -s' code for c_rehash. But I can't get it to work. I always get an ssl handshake failure. Sample failed output below. snip rest You're looking in entirely the wrong place. Even if symlinks work on Windows and I'm not sure about that, CApath and/or CAfile supply CA certs to use to verify the *server* (in general the peer, which for s_client is the server), *not* prove the client, and no key(s) at all (which is necessary for client to prove). I believe, but haven't tracked down exactly, the default truststore (CApath and/or CAfile) is used to *add* chain certs for the client cert if needed, but it cannot be used to supply the client cert (and key) itself. In general if you want to interactively select client cert+key, you need to set _client_cert_cb (callback) or _client_cert_engine. s_client.c currently has the latter, if you write such an engine; or you can modify s_client.c to include and use a callback you write. Or you could write a custom app which just SSL_connect's and displays the server cert (or only server cert notAfter if that's all you want) and doesn't try to do the many other things s_client does. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
