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

[Jochen Bern]

On 11/02/2011 12:08 PM, al_9x at yahoo.com wrote:
> On 11/2/2011 6:39 AM, Ludolf Holzheid wrote:
>> On Wed, 2011-11-02 05:41:57 -0400, al_9x at yahoo.com wrote:
>>> The concept of trusted server certs (as opposed to trusted authority
>>> certs) is well established.  Firefox cert manager, for example, has a
>>> servers tab where you can import and trust specific server certs (self
>>> signed and not)
>> And Firefox accepts such certificates even if they can't be validated
>> (and thus are to be considered invalid)?I would regard this as a bug
>> or at least as a design flaw...

FWIW: Yes, that's what web browsers do. That's because they live in the
world of the WWW, which adopted HTTP+SSL primarily as a means to achieve
secrecy (encryption) and would (well, most of them) happily drop
authentication (server certs) on the floor *if only* the SSL standards
allowed that. Self-signed server certs created automagically the first
time you start your newly installed webserver software express the same
stance. In this notion, the server key+cert pair *really* is nothing but
a glorified challenge-response mechanism, no third parties required.

For the exact same reason, Firefox et.al. do *not* use OpenSSL or any
work derived thereof as their SSL engine, do not identify certificates
the same way OpenSSL does (hash numbers), etc. etc..

> They *are* validated, by the user's explicit grant of trust to the
> imported server cert.  The flaw is not in Firefox but your understanding
> of trust.  The reason you walk the trust chain to a trusted root is
> because normally (standard PKI model) you don't trust individual server
> certs, but only CA roots.  However if (for whatever reason) you do
> explicitly trust a server cert, no further validation is needed.

Whether "the PKI model" ***ALLOWS*** overlaying a Web of Trust in
addition to the hierarchical structure is debatable. As I already
mentioned, not going through the CA certs effectively disables
(automated) CRL checking, which is a pretty dubious "improvement".

And since I'm already rephrasing myself, I *still* think that OpenSSL
based software - like stunnel - actually can't do squat to implement
your proposed behavior.

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