Hi Dave, 2008/10/4 Dave Thompson <[EMAIL PROTECTED]>: >> 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.
Yes. Good spot. A sausage-fingers error as a result of the reason you guessed. >> 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. Ah. This makes sense. I'll have a look at the chain in IE. > 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. Is it usual for the client to have to provide the signing certificates? I would have thought that the server would have them when certificates are being used for authentication. > 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.) I believe there is an intermediate certificate but I have every reason to believe that the server will have a copy... It looks like I need to find the Verisign certificate from in IE. > 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. Yep. Got bored of typing the passphrase. They're testing certificates so they'll be revoked and deleted once we've finished. Thanks for the explanation. I'm guessing that IE must have something in its store which is working, so I'll have a dig around in there. Regards, Felix ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
