[stunnel-users] Weird verify behaviour using intermediate CAs

delaage.pierre at free.fr delaage.pierre at free.fr
Sun Oct 4 07:23:15 CEST 2009

You are right that my suggestions only work with verify = 3.
But with verify=2, you should try this :
CApath empty
CAfile containing a concatenation of the ONLY intermediate CA certs you really
CRLfile: a regularly updated (cron/wget) concatenation of crls from the CA you


Quoting Simon Vallet <sjv at genoscope.cns.fr>:

> On Thu, 01 Oct 2009 06:44:12 +0200
> delaage.pierre at free.fr wrote:
> > Everything should work "securely" once you have usercert2 hash present in
> your
> > CApath (and client cert file present of course somewhere on the server),
> and
> > that there is really a chain from that cert to the related rootca (the
> chain
> > should be present in the client cert file, so there is no need to declare
> chains
> > in stunnel server conf file).
> Hmmm. That would be the necessary setup with verify=3, right ? I agree
> that it would be more secure, but having to list every issued client
> cert there does not scale very well.
> > What would be really worrying would be if usercert2 was validated while
> being
> > not present in CApath: but this is not the case, isn't it...
> OK. I think I misunderstood the purpose of CApath: I was under the
> impression that only the signing CA (in our case, the intermediate one)
> was significant. Instead it seems that the root of the chain is
> actually checked.
> So I guess there's no way to have stunnel discriminate users based upon
> an intermediary CA, then (except with verify=3) ?
> Simon

More information about the stunnel-users mailing list