Re: [stunnel-users] Why does verify=3 require the entire cert chain to be present in cafile?
On 10/25/2011 09:54 PM, [email protected] 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.
2. Certificates are to be considered invalid once they have been revoked, and in order to check the CRL, you have to determine the issuing CA. Whose certificate has to be checked against its parent CA, etc. all the way to the Root CA. A "verification" mechanism which does not check for explicit revocation would have to be considered faulty for *most*, if not all, application cases - the fact that automated CRL checking is still pretty much absent in mechanisms which do not *mandate* a working Internet connection notwithstanding.
3. Since you're apparently trying to set up a point-to-point SSL connection with preconfigured direct trust, my guess would be that you'd be better off if the server would use a self-signed cert (either altogether, or in addition to the current one - say, on an additional port). However, since you never mentioned what kind of software you're trying to get to talk to each other, I'm at a loss suggesting *how* you might do that.
Regards, J. Bern
On 10/26/2011 3:43 AM, Jochen Bern wrote:
On 10/25/2011 09:54 PM, [email protected] 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.
On 10/26/2011 05:56 PM, [email protected] wrote:
On 10/26/2011 3:43 AM, Jochen Bern wrote:
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.
Unlike with stunnel, I'm able to forgo belief and put OpenSSL to the test pretty much wherever my laptop happens to be running:
$ openssl s_client -showcerts -connect imaps:imaps > Server.crt 2>&1 1 LOGOUT
$ grep -n CERT Server.crt 15:-----BEGIN CERTIFICATE----- 35:-----END CERTIFICATE-----
$ openssl s_client -verify 5 -CAfile Server.crt \
-connect imaps:imaps 2>&1 | grep Verify
Verify return code: 21 (unable to verify the first certificate) 1 LOGOUT
$ openssl s_client -verify 5 -CAfile /etc/openvpn/*-ca-cert.pem \
-connect imaps:imaps 2>&1 | grep Verify
Verify return code: 0 (ok) 1 LOGOUT
Regards, J. Bern
-
al_9x＠yahoo.com -
Jochen Bern