> 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
