> From: [EMAIL PROTECTED] On Behalf Of Felix Ingram > Sent: Tuesday, 30 September, 2008 10:08
> I'm having a little trouble testing out some web services for a > client. They have provided us with a couple of pfx certificate files > to allow us to authenticate to their web servers. <snip> > openssl s_client -connect weburl.com/pageIWant:443 -cert TEST35.pem weburl.com is an actual host on the public Internet, but does not appear to support SSL, at least not on 443. I'm guessing you used that as a dummy value to hide the host you're actually using. But that syntax shouldn't work. You put only host:port after -connect, and then enter the http request (GET $url $proto, (v)Host: etc. as needed) AFTER CONNECTION, or redirect it from a file. Unless you're actually using an IPaddress instead e.g. #.#.#.#/foo[:port] then the /foo is just ignored. > > and get the following. > > Loading 'screen' into random state - done > CONNECTED(00000694) > depth=1 /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign > International Server CA - Class 3/OU > =www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign > verify error:num=20:unable to get local issuer certificate > verify return:0 > 3704:error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown > ca:.\ssl\s3_pkt.c:1057:SSL alert number 48 > 3704:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake > failure:.\ssl\s23_lib.c:188: > > I've converted the pfx to a pem with whichever command Google gave me. > I'm guessing that this is a problem with the client certificate rather > than the server certificate. > The verify error & verify return 0 is about the server certificate, but is nonfatal by default in s_client. To avoid it, you need to provide the CAcert that signed the server's cert (here Verisign Class 3) using -CAfile or -CApath. If IE is accepting this website without cavil, and you haven't turned off cert warnings in IE, then it has the CAcert in its trusted store, and you can export a copy from there into a file which you give to openssl. The actual failure is the alert 48 "unknown ca" from the server. Apparently it doesn't like the cert (or chain) s_client is sending, but the protocol doesn't provide any (standard) way for it to explain. If they have logs on the server, and you can reach someone who knows about them, ask them to look at the time of your failed attempt(s) and see if it has any more specific or descriptive information. And/or look at the Issuer field of the certificate (aka identity) THAT YOU USED in IE's trusted store, and compare it manually to the (end-entity) cert shown by (something like) openssl x509 -in TEST35.pem -text -noout to make certain both are actually using/asking for the same thing. Also see if the Certification Path shown by IE for the cert has any intermediate cert(s) before it gets to a CA (likely) known by the server. If so, I think you have a problem; I don't see any way for s_client to add additional cert(s) to its (temporary) cert_store to be sent. Unless you can get the server folks to add it/them to THEIR trusted store. (In principle if it validates under a CA they trust, there's no logical reason not to trust it; but depending on the server and the people who operate it, making these kind of changes can be very sensitive.) PS- You didn't show, or mention, entering a passphrase for your privatekey. I'm guessing this means you extracted the pfx(PKCS12) into TEST35.pem with -nodes among other things. I hope you realize that in general storing a privatekey in clear means that anyone who gets at the file(s) on your system, or your disk perhaps even after you delete the file(s), can break the security that key is for -- here, impersonate you. If this is an identity only authorized (and used) for testing, this may be no problem, but it is not a good habit to form. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
