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@genoscope.cns.fr:
On Sun, 04 Oct 2009 07:23:15 +0200 delaage.pierre@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