On 10/25/2011 09:54 PM, [email protected] wrote:

verify=3 means checking is done against local certs. My point is that if the actual server cert is stored locally (i.e. trusted) that should be enough. When I put just the server cert in cafile validation (and connection) fails, but when I put the whole chain, it succeeds. Why isn't the server cert sufficient?

Mostly guessing here, but: 1. stunnel uses the OpenSSL libraries. The verify(1) manpage says: "The verify program uses the same functions as the internal SSL and S/MIME verification, therefore this description applies to these verify operations too. [...] The verify operation consists of a number of separate steps. Firstly a certificate chain is built up starting from the supplied certificate and ending in the root CA. It is an error if the whole chain cannot be built up. The chain is built up by looking up the issuers certificate of the current certificate. If a certificate is found which is its own issuer it is assumed to be the root CA." -- http://www.openssl.org/docs/apps/verify.html#VERIFY_OPERATION So I'd guess that the algorithm you're at odds with is part of OpenSSL, rather than something stunnel can change. 2. Certificates are to be considered invalid once they have been revoked, and in order to check the CRL, you have to determine the issuing CA. Whose certificate has to be checked against its parent CA, etc. all the way to the Root CA. A "verification" mechanism which does not check for explicit revocation would have to be considered faulty for *most*, if not all, application cases - the fact that automated CRL checking is still pretty much absent in mechanisms which do not *mandate* a working Internet connection notwithstanding. 3. Since you're apparently trying to set up a point-to-point SSL connection with preconfigured direct trust, my guess would be that you'd be better off if the server would use a self-signed cert (either altogether, or in addition to the current one - say, on an additional port). However, since you never mentioned what kind of software you're trying to get to talk to each other, I'm at a loss suggesting *how* you might do that. Regards, J. Bern -- Jochen Bern, Systemingenieur --- LINworks GmbH <http://www.LINworks.de/> Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel