Hi,
we're trying to make use of stunnel here for proxy purposes : any certificate-authenticated SSL client connection from the Internet would be forwarded to some internal server.
This works fine, but I found some surprising behaviour when verifying client certificates. Consider the following setup, using an intermediate client CA :
* RootCA ** UserCA1 *** UserCert1
** UserCA2 *** UserCert2
To make this work, it seems I only have to include the Root CA certificate in either a CAfile or a directory of trusted certificates. I would have expected to have to include the intermediate CA (which is signing the user certificate), but it seems it is not the case.
What worries me is that now *any* end-entity certificate which has been issued by *other* intermediate CAs is accepted as valid, i.e. UserCert2 is accepted as valid, even if I don't include UserCA2 anywhere in the configuration.
Is this really the intended behaviour ? If not, what would I be missing ?
Simon
stunnel.conf -----------------------------------------------------------
connect = 127.0.0.1:25 CApath = /etc/stunnel/certs cert = /etc/stunnel/apollon.genoscope.cns.fr-RevChain.pem key = /etc/stunnel/apollon.genoscope.cns.fr-Key.pem verify = 2 debug = 7
------------------------------------------------------------------------
[root@apollon certs]# ls -l /etc/stunnel/certs/ total 4 lrwxrwxrwx 1 root root 28 sep 30 11:01 9a5490ff.0 -> GenoscopeACRacine.cacert.pem -rw-r--r-- 1 root root 2269 sep 15 11:47 GenoscopeACRacine.cacert.pem [root@apollon certs]#
Hello, 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). If it is the case, we can say that your server has issued the client certificate, in a way or another, and client cert validation will work.
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...
Pierre
Quoting Simon Vallet [email protected]:
Hi,
we're trying to make use of stunnel here for proxy purposes : any certificate-authenticated SSL client connection from the Internet would be forwarded to some internal server.
This works fine, but I found some surprising behaviour when verifying client certificates. Consider the following setup, using an intermediate client CA :
- RootCA
** UserCA1 *** UserCert1
** UserCA2 *** UserCert2
To make this work, it seems I only have to include the Root CA certificate in either a CAfile or a directory of trusted certificates. I would have expected to have to include the intermediate CA (which is signing the user certificate), but it seems it is not the case.
What worries me is that now *any* end-entity certificate which has been issued by *other* intermediate CAs is accepted as valid, i.e. UserCert2 is accepted as valid, even if I don't include UserCA2 anywhere in the configuration.
Is this really the intended behaviour ? If not, what would I be missing ?
Simon
stunnel.conf -----------------------------------------------------------
connect = 127.0.0.1:25 CApath = /etc/stunnel/certs cert = /etc/stunnel/apollon.genoscope.cns.fr-RevChain.pem key = /etc/stunnel/apollon.genoscope.cns.fr-Key.pem verify = 2 debug = 7
[root@apollon certs]# ls -l /etc/stunnel/certs/ total 4 lrwxrwxrwx 1 root root 28 sep 30 11:01 9a5490ff.0 -> GenoscopeACRacine.cacert.pem -rw-r--r-- 1 root root 2269 sep 15 11:47 GenoscopeACRacine.cacert.pem [root@apollon certs]# _______________________________________________ stunnel-users mailing list [email protected] http://stunnel.mirt.net/mailman/listinfo/stunnel-users
On Thu, 01 Oct 2009 06:44:12 +0200 [email protected] 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
Well, 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. CRLfile: a regularly updated (cron/wget) concatenation of crls from the CA you need.
Pierre
Quoting Simon Vallet [email protected]:
On Thu, 01 Oct 2009 06:44:12 +0200 [email protected] 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
On Sun, 04 Oct 2009 07:23:15 +0200 [email protected] 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
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 [email protected]:
On Sun, 04 Oct 2009 07:23:15 +0200 [email protected] 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
On Mon, 05 Oct 2009 15:09:02 +0200 [email protected] wrote:
Good new, "Actually, it also works when using CApath". I suppose you mean it also works without (it should).
It does (see the first two points). Both do.
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.
I've grown into the habit of using CApath since some CRL-checking daemons do not provide for a separate CRLfile/CRLpath parameter and use the same directory for trusted CAs and corresponding CRLs. It's mostly a convenience setup so I can reuse existing scripts et al.
Regards, Simon
-
delaage.pierre＠free.fr -
Simon Vallet