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 List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
