[stunnel-users] Weird verify behaviour using intermediate CAs

[delaage.pierre at free.fr]

Good new,
"Actually, it also works when using CApath".
I suppose you mean it also works without (it should).
Since you are not using verify=3, you do not need CApath and it seems that it
can only lead to bugs in your setup.I even wonder what you could put in that
directive that could make sense in your config.

Best regards,
Pierre




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

>
> On Sun, 04 Oct 2009 07:23:15 +0200
> delaage.pierre at free.fr wrote:
>
> > 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
> > want.
>
> OK, here are the results:
>
> - CAfile containing only the intermediate CA cert I want to trust:
>
> LOG4[32456:3086175120]: VERIFY ERROR: depth=1, error=unable to get
> issuer certificate: [...]
> LOG7[32456:3086175120]: SSL alert (write): fatal: unknown CA
>
> which seems reasonable.
>
> - CAfile containing the intermediate CA I want to trust and the Root CA:
>
> LOG6[32464:3086822288]: SSL accepted: new session negotiated
>
> this works, and trying to authenticate with a certificate issued by
> another sub CA does not work (good news ;-)
>
> Actually, it also works when using CApath -- the issue I encountered
> apparently only occurs if you add, then remove a CA certificate from
> the CApath: if I added a subCA certificate and the corresponding link
> to the path, test the connection, and then removed them, I could still
> authenticate, which I found weird, since the setup is in inetd-mode (so
> stunnel would be started from scratch at each connection).
>
> I can't reliably reproduce the issue today -- maybe some kind
> of race-condition ?
>
> Anyway, I can separate users based on their issuing CA now, so I guess
> everything is fine.
>
> Thanks,
> Simon
>