thanks dave and martin. with all that information i think i should start the process again. Do you have some materials that have step by step process of configuring two way connections
On Fri, Jan 10, 2014 at 7:30 AM, Dave Thompson <dthomp...@prinpay.com>wrote: > > From: owner-openssl-users On Behalf Of Martin Hecht > > Sent: Thursday, January 09, 2014 11:54 > > Generally good explanation, but a few quibbles: > > > I don't know what exactly you are doing, so it is difficult to speculate > > why you are receiving code 19. > > > > Some information is exchanged during establishment of the ssl > > connection. For example if you have a web server and a browser, the web > > server shows the host certificate to the browser and the browser has to > > verify it. Browsers don't have all certificates in their certificate > > store, but they have the trusted root-CA certs. So it is up to the web > > server to deliver the whole chain (including the sub-CA certificates). > > Then, the browser checks, if the host certificate matches the hostname, > > if the host certificate is issued by the intermediate CA, if the > > intermediate CA cert is issued by a superior CA, and so on, until it > > finds a self-singed CA certificate. That's the root CA certificate. Now, > > the browser checks if that particular rootCA certificate is among the > > ones the browser has configured as trusted root-CAs. In order to quickly > > Mostly concur, although I would say 'sends' instead of vague 'shows' or > conclusive 'delivers'. And openssl to date can only configure roots > as trusted, but (most?) other browsers and clients can have non-root > trust 'anchors' configured and it has been stated openssl 1.0.2 will > add that capability. Also it is possible for certs to specify a way > (AIA.caIssuers) for the client to fetch chain cert(s) even if > the server doesn't send them, but I don't think this is much > implemented yet and certainly not by openssl. So a public server > should send the full chain except optionally root; a server that > only handles limited clients might not need to. > > > find the correct file in the directory, it calculates the hash on the > > certificate's subject and looks for such a file. If it finds one and it > > openssl by default supports both a directory containing cert files > (and CRL files if used) named by the subject (resp. issuer) hash > plus a suffix, AND a single file containing a series of certs (and CRLs). > The latter is a little easier to set up, and the OP might try it instead. > Also, probably not an issue this time but openssl 1.0.0 changed the > name-hash algorithm, so in some situations you need to re-hash. > > > is the same certificate, then it has successfully verified the chain and > > verified that the CA is trustworthy. There are some more advanced things > > like checking that none of the certificates has expired, that the > > revocation lists are up to date and the certificates have not been > > revoked, but I'd ignore this for the moment. > > > Since those wouldn't lead to error 19 (although some of them, > particularly as I recall AKI and KU, can lead to error 20). > > > In your case all certificates have been found (either in a local > > directory or they have been transmitted during establishment of the > > connection), but the last step to find the rootCA certificate among the > > trusted certificates did not succeed. It could as well be that your > > application has its own certificate store (like Mozilla browsers or > > Tomcat web server for instance). > > > Mozilla uses NSS, IE uses the Windows store as does Chrome on Windows, > I believe Chrome on Mac and Safari use MacOS something, Tomcat/JSSE > uses a Java store. But Tomcat/APR uses openssl, (nearly) like httpd. > I don't know of any web browser that uses libssl, although it's possible. > (maybe lynx? curl and I think wget do, if you count those.) Some SSL > clients for non-web services do use openssl. > > <snip earlier> > > But the OP mentioned "two way connection", which may be intended > to mean client authentication, often called mutual authentication or > two-way authentication, in which case her problem could be on the > client->server direction instead. If so the same principles apply in > reverse: > the client should be configured to send the chain and the server if openssl > must have in its truststore at least the root used by the client. > > Although if there is only one or a few servers that you control, you may > prefer to put chain cert(s) needed by the clients in the server > truststore(s) > which openssl will use rather than (re)configure a large number of clients. > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
