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(000000AC)
depth=1 /C=US/ST=Illinois/L=Quincy/O=Leverage
Discovery/OU=Administration/CN=CA
VERIFIER/emailAddress=supp...@test.net<mhtml:{0A5176EE-A535-4161-97E6-387F35505019}mid://00001174/!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.net<mhtml:{0A5176EE-A535-4161-97E6-387F35505019}mid://00001174/!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.net<mhtml:{0A5176EE-A535-4161-97E6-387F35505019}mid://00001174/!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.net<mhtml:{0A5176EE-A535-4161-97E6-387F35505019}mid://00001174/!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.net<mhtml:{0A5176EE-A535-4161-97E6-387F35505019}mid://00001174/!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.net<mhtml:{0A5176EE-A535-4161-97E6-387F35505019}mid://00001174/!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
AAGjggEhMIIBHTAJBgNVHRMEAjAAMCwGCWCGSAGG+EIBDQQfFh1PcGVuU1NMIEdl
bmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUqBcWcEb6ULtlu/KtA0BDD6/f
HukwgcIGA1UdIwSBujCBt6GBqaSBpjCBozELMAkGA1UEBhMCVVMxETAPBgNVBAgT
CElsbGlub2lzMQ8wDQYDVQQHEwZRdWluY3kxGzAZBgNVBAoTEkxldmVyYWdlIERp
c2NvdmVyeTEXMBUGA1UECxMOQWRtaW5pc3RyYXRpb24xFDASBgNVBAMTC0NBIFZF
UklGSUVSMSQwIgYJKoZIhvcNAQkBFhVzdXBwb3J0QGdhcmV4Lm5ldC5jb22CCQDG
XJsdj9DZ4DANBgkqhkiG9w0BAQUFAANBAJ6lHB/biy2rl9dUKz2t3jQscPmeTg1G
SnDKYMyZrYp5AfUN3uuAsNRzJIDVHk4dBsIqdsrfxTxBj3vfQYdMYJQ=
-----END CERTIFICATE-----
subject=/C=US/ST=Illinois/O=Leverage
Discovery/OU=Administration/CN=192.168.1.145/emailAddress=supp...@test.net<mhtml:{0A5176EE-A535-4161-97E6-387F35505019}mid://00001174/!x-usc:mailto:Discovery/OU=Administration/CN=192.168.1.145/emailAddress=supp...@test.net>
issuer=/C=US/ST=Illinois/L=Quincy/O=Leverage
Discovery/OU=Administration/CN=CA
VERIFIER/emailAddress=supp...@test.net<mhtml:{0A5176EE-A535-4161-97E6-387F35505019}mid://00001174/!x-usc:mailto:VERIFIER/emailAddress=supp...@test.net>
---
Acceptable client certificate CA names
/C=US/ST=Illinois/L=Quincy/O=Leverage Discovery/OU=Administration/CN=CA
VERIFIER/emailAddress=supp...@test.net<mhtml:{0A5176EE-A535-4161-97E6-387F35505019}mid://00001174/!x-usc:mailto:VERIFIER/emailAddress=supp...@test.net>
---
SSL handshake has read 2036 bytes and written 210 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 512 bit
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : DHE-RSA-AES256-SHA
Session-ID:
Session-ID-ctx:
Master-Key:
1EBADE731375C8F76334F1DA75E45E6BB33752EBBEE36ADA6212F5CBCD7A5A126A256952F207E32B8CDBD6FC3416F8FF
Key-Arg : None
PSK identity: None
PSK identity hint: None
Start Time: 1328300988
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
=======================================

Diff for the s_client code to allow batch commands on Windows to timeout
properly:
=======================================
Left file: s_client-1.0.0-beta3-original.c
Right file: s_client-mods-for-nowait.c
285c285
<
---
> BIO_printf(bio_err," -nowait - exit after dumping info; enables batch
mode\n");
435a436
> int enable_nowait = 0;
536a538,539
> else if (strcmp(*argv,"-nowait") == 0)
> enable_nowait=1;
1248a1252,1260
> else
> {
> if (enable_nowait)
> {
> BIO_printf(bio_c_out,"DONE\n");
> ret = 0;
> goto shut;
> }
> }
=======================================

Reply via email to