If the leaf (server) cert is declared trusted (added to the cafile), there is no point in walking the trust chain.
On 10/15/2011 6:37 AM, [email protected] wrote:
If the leaf (server) cert is declared trusted (added to the cafile), there is no point in walking the trust chain.
Please explain why it's necessary to add the whole chain to cafile. Why is just the server cert insufficient?
Thanks.
On 10/15/2011 6:37 AM, [email protected] wrote:
If the leaf (server) cert is declared trusted (added to the cafile), there is no point in walking the trust chain.
Michal Trojnara, can you comment please? Can you support a mode of validation that allows one to trust the server certificate, without having to add the whole chain?
On Tue, 2011-11-01 23:11:45 -0400, [email protected] wrote:
On 10/15/2011 6:37 AM, [email protected] wrote:
If the leaf (server) cert is declared trusted (added to the cafile), there is no point in walking the trust chain.
Michal Trojnara, can you comment please? Can you support a mode of validation that allows one to trust the server certificate, without having to add the whole chain?
al_9x,
I think the technical issue has been discussed already.
Could you please provide a rationale for insisting in not using self-singed certificates /and/ for refusing to have the one or two additional certificates installed?
Ludolf
On 11/2/2011 4:49 AM, Ludolf Holzheid wrote:
On Tue, 2011-11-01 23:11:45 -0400, [email protected] wrote:
On 10/15/2011 6:37 AM, [email protected] wrote:
If the leaf (server) cert is declared trusted (added to the cafile), there is no point in walking the trust chain.
Michal Trojnara, can you comment please? Can you support a mode of validation that allows one to trust the server certificate, without having to add the whole chain?
al_9x,
I think the technical issue has been discussed already.
Could you please provide a rationale for insisting in not using self-singed certificates
stunnel can be used in client mode to connect to servers one does not control
/and/ for refusing to have the one or two additional certificates installed?
one or two or three or four or five
I already explained that when you chose to trust a specific server cert, the CA certs (intermediate and root) up the chain are irrelevant, it is pointless to verify them and only creates unnecessary work.
The concept of trusted server certs (as opposed to trusted authority certs) is well established. Firefox cert manager, for example, has a servers tab where you can import and trust specific server certs (self signed and not)
On Wed, 2011-11-02 05:41:57 -0400, [email protected] wrote:
The concept of trusted server certs (as opposed to trusted authority certs) is well established. Firefox cert manager, for example, has a servers tab where you can import and trust specific server certs (self signed and not)
And Firefox accepts such certificates even if they can't be validated (and thus are to be considered invalid)? I would regard this as a bug or at least as a design flaw...
BTW, Firefox comes with about 200 certificates installed, and 200 is much larger than five, which seems to be a pain for you.
Ludolf
On 11/2/2011 6:39 AM, Ludolf Holzheid wrote:
On Wed, 2011-11-02 05:41:57 -0400, [email protected] wrote:
The concept of trusted server certs (as opposed to trusted authority certs) is well established. Firefox cert manager, for example, has a servers tab where you can import and trust specific server certs (self signed and not)
And Firefox accepts such certificates even if they can't be validated (and thus are to be considered invalid)?I would regard this as a bug or at least as a design flaw...
They *are* validated, by the user's explicit grant of trust to the imported server cert. The flaw is not in Firefox but your understanding of trust. The reason you walk the trust chain to a trusted root is because normally (standard PKI model) you don't trust individual server certs, but only CA roots. However if (for whatever reason) you do explicitly trust a server cert, no further validation is needed.
On 11/02/2011 12:08 PM, [email protected] wrote:
On 11/2/2011 6:39 AM, Ludolf Holzheid wrote:
On Wed, 2011-11-02 05:41:57 -0400, [email protected] wrote:
The concept of trusted server certs (as opposed to trusted authority certs) is well established. Firefox cert manager, for example, has a servers tab where you can import and trust specific server certs (self signed and not)
And Firefox accepts such certificates even if they can't be validated (and thus are to be considered invalid)?I would regard this as a bug or at least as a design flaw...
FWIW: Yes, that's what web browsers do. That's because they live in the world of the WWW, which adopted HTTP+SSL primarily as a means to achieve secrecy (encryption) and would (well, most of them) happily drop authentication (server certs) on the floor *if only* the SSL standards allowed that. Self-signed server certs created automagically the first time you start your newly installed webserver software express the same stance. In this notion, the server key+cert pair *really* is nothing but a glorified challenge-response mechanism, no third parties required.
For the exact same reason, Firefox et.al. do *not* use OpenSSL or any work derived thereof as their SSL engine, do not identify certificates the same way OpenSSL does (hash numbers), etc. etc..
They *are* validated, by the user's explicit grant of trust to the imported server cert. The flaw is not in Firefox but your understanding of trust. The reason you walk the trust chain to a trusted root is because normally (standard PKI model) you don't trust individual server certs, but only CA roots. However if (for whatever reason) you do explicitly trust a server cert, no further validation is needed.
Whether "the PKI model" ***ALLOWS*** overlaying a Web of Trust in addition to the hierarchical structure is debatable. As I already mentioned, not going through the CA certs effectively disables (automated) CRL checking, which is a pretty dubious "improvement".
And since I'm already rephrasing myself, I *still* think that OpenSSL based software - like stunnel - actually can't do squat to implement your proposed behavior.
Regards, J. Bern
OP did not ask for PKI. It is obvious that directly trusted server certificate cannot be revoked. The necessary option is that ANY directly trusted certificate should be treated as self signed. (For example server cert is trusted, but CA is not) There might be other users, who trusts CA, but does not trusts server cert directly, so server cert were signed by CA for sake of that subset of users.
----- Original Message ----- From: "Jochen Bern" [email protected] To: [email protected] Sent: Wednesday, November 02, 2011 2:05 PM Subject: Re: [stunnel-users] Why does verify=3 require the entire cert chain to be present in cafile?
Whether "the PKI model" ***ALLOWS*** overlaying a Web of Trust in addition to the hierarchical structure is debatable. As I already mentioned, not going through the CA certs effectively disables (automated) CRL checking, which is a pretty dubious "improvement".
[email protected] wrote:
If the leaf (server) cert is declared trusted (added to the cafile), there is no point in walking the trust chain.
Michal Trojnara, can you comment please? Can you support a mode of validation that allows one to trust the server certificate, without having to add the whole chain?
RFC 2246, section 7.4.2 (Server certificate) says:
certificate_list This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.
Not validating the chain would violate the protocol requirements.
With "verify=3" you don't really need the whole chain to be in your CAfile: just the root certificate and the leaf certificate.
Mike
On 11/2/2011 12:22 PM, Michal Trojnara wrote:
Not validating the chain would violate the protocol requirements.
I am not suggesting you should abandon normal CA based validation, but that in addition to it, you could support an alternative validation model where the user can grant trust to the server cert, which renders any further validation unnecessary. Considering you support running without any validation whatsoever, doesn't make sense that you object to this alternative approach.
[email protected] wrote:
I am not suggesting you should abandon normal CA based validation, but that in addition to it, you could support an alternative validation model where the user can grant trust to the server cert, which renders any further validation unnecessary. Considering you support running without any validation whatsoever, doesn't make sense that you object to this alternative approach.
Makes sense indeed.
Just to be sure I understand your needs: the server would send the whole chain, but the client would only verify the peer certificate, right? Otherwise it might be hard to perform peer certificate validation without its signing certificate.
Mike
[email protected] wrote:
I am not suggesting you should abandon normal CA based validation, but that in addition to it, you could support an alternative validation model where the user can grant trust to the server cert, which renders any further validation unnecessary. Considering you support running without any validation whatsoever, doesn't make sense that you object to this alternative approach.
I've implemented this functionality as "verify=4".
Please test it and let us know if that's what you expected: ftp://ftp.stunnel.org/stunnel/stunnel-4.46b2.tar.gz
A similar idea was proposed for the OpenSSL protocol itself: https://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01
Best regards, Michal Trojnara
I wrote:
Please test it and let us know if that's what you expected: ftp://ftp.stunnel.org/stunnel/stunnel-4.46b2.tar.gz
I found an error! Please try: ftp://ftp.stunnel.org/stunnel/stunnel-4.46b3.tar.gz
Mike
On 11/3/2011 7:35 AM, Michal Trojnara wrote:
I wrote:
Please test it and let us know if that's what you expected: ftp://ftp.stunnel.org/stunnel/stunnel-4.46b2.tar.gz
I found an error! Please try: ftp://ftp.stunnel.org/stunnel/stunnel-4.46b3.tar.gz
Appears to be working, thanks. A couple of questions about verify=4:
1. Are the certificates restricted to the host(s) specified in them (CN, alt name)? Or will they validate any site that happens to return them?
2. I think some host restriction makes sense, but rather than use what's inside the cert, it would be good to allow the user to specify the host name(s) which a given cert should be restricted to.
3. The certificates are only used for server verification, they would never be treated as CA, right?
[email protected] wrote:
- Are the certificates restricted to the host(s) specified in them
(CN, alt name)? Or will they validate any site that happens to return them?
Hostname checks against distinguished name and alternative name fields are not supported by stunnel. They would would not be really useful, as "connect" targets are statically defined in stunnel.conf. It's easier and more secure to assign separate CAfile to each service section of stunnel.conf (see an example below).
- I think some host restriction makes sense, but rather than use
what's inside the cert, it would be good to allow the user to specify the host name(s) which a given cert should be restricted to.
client = yes verify = 3 (or 4)
[section1] accept = port1 connect = target1 CAfile = target1.pem
[section2] accept = port2 connect = target2 CAfile = target2.pem
- The certificates are only used for server verification, they
would never be treated as CA, right?
Yes, OpenSSL checks certificate purpose specified in X.509 v3 basicConstraints.
See openssl-1.0.0e/crypto/x509v3/v3_purp.c file for the implementation.
Mike
-
al_9x＠yahoo.com -
Jochen Bern -
Ludolf Holzheid -
Michal Trojnara -
yyy