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 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. > > 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 > > 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 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. > > > 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 >
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.netmailto: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.netmailto: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.netmailto: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.netmailto:VERIFIER/emailAddress=supp...@test.net> 1 s:/C=US/ST=Illinois/L=Quincy/O=Leverage Discovery/OU=Administration/CN=CA VERIFIER/emailAddress=supp...@test.netmailto:VERIFIER/emailAddress=supp...@test.net> i:/C=US/ST=Illinois/L=Quincy/O=Leverage Discovery/OU=Administration/CN=CA VERIFIER/emailAddress=supp...@test.netmailto: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 AAGjggEhMIIBHTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdl bmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUqBcWcEb6ULtlu/KtA0BDD6/f HukwgcIGA1UdIwSBujCBt6GBqaSBpjCBozELMAkGA1UEBhMCVVMxETAPBgNVBAgT CElsbGlub2lzMQ8wDQYDVQQHEwZRdWluY3kxGzAZBgNVBAoTEkxldmVyYWdlIERp c2NvdmVyeTEXMBUGA1UECxMOQWRtaW5pc3RyYXRpb24xFDASBgNVBAMTC0NBIFZF UklGSUVSMSQwIgYJKoZIhvcNAQkBFhVzdXBwb3J0QGdhcmV4Lm5ldC5jb22CCQDG XJsdj9DZ4DANBgkqhkiG9w0BAQUFAA
