[stunnel-users] Why does verify=3 require the entire cert chain to be present in cafile?

Wed Oct 26 09:43:45 CEST 2011

On 10/25/2011 09:54 PM, al_9x at yahoo.com 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