On 10/26/2011 3:43 AM, Jochen Bern wrote:
On 10/25/2011 09:54 PM, al_9x@yahoo.com wrote:
verify=3 means checking is done against local certs. My point is that if the actual server cert is stored locally (i.e. trusted) that should be enough. When I put just the server cert in cafile validation (and connection) fails, but when I put the whole chain, it succeeds. Why isn't the server cert sufficient?
Mostly guessing here, but:
- stunnel uses the OpenSSL libraries. The verify(1) manpage says:
"The verify program uses the same functions as the internal SSL and S/MIME verification, therefore this description applies to these verify operations too. [...] The verify operation consists of a number of separate steps.
Firstly a certificate chain is built up starting from the supplied certificate and ending in the root CA. It is an error if the whole chain cannot be built up. The chain is built up by looking up the issuers certificate of the current certificate. If a certificate is found which is its own issuer it is assumed to be the root CA." -- http://www.openssl.org/docs/apps/verify.html#VERIFY_OPERATION
So I'd guess that the algorithm you're at odds with is part of OpenSSL, rather than something stunnel can change.
Trusting a specific server cert is a viable validation strategy, I doubt openssl makes that impossible. Currently stunnel requires the local presence of all the certs in a chain, but as I keep pointing out, if you have declared the server cert itself trusted, it should not be necessary to walk the trust chain to the root ca. The whole point of walking the trust chain is to arrive at a cert that is trusted, but if the server cert itself is trusted, there is no point. Validation should stop at the highest cert in the chain that is declared trusted, in this case it's the server cert.