[stunnel-users] Why does verify=3 require the entire cert chain to be present in cafile?

al_9x at yahoo.com al_9x at yahoo.com
Wed Oct 26 17:56:43 CEST 2011


On 10/26/2011 3:43 AM, Jochen Bern wrote:
> On 10/25/2011 09:54 PM, al_9x at 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:
>
> 1. 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.





More information about the stunnel-users mailing list