On Wed, 2016-03-02 at 09:58 -0500, David Duchaine wrote: > 2016-03-02 8:14 GMT-05:00 Oleg Kalnichevski <[email protected]>: > > > On Wed, 2016-03-02 at 08:02 -0500, David Duchaine wrote: > > > The point of making it trust certificates indiscriminately is that if > > you make your code trust a self-signed cert, which is considered not > > secure, why would’nt you want it to connect to a signed cert, which is > > probably not more or less secure…. > > > > > > The thing is, I had a really hard time finding why my code wasn’t > > connecting to server B, which had a signed, chained certificate > > (chain.length = 3). However , it was possible to connect to server A which > > was also signed, but without presenting a chained cert (chain.length == 1) > > > > > > > > A self-signed cert is the one that has only itself in its trust chain. > > > > After some research, I think this is correct. But it is possible to have a > chain.length == 1 for a certificate that is signed by a CA. When this is > the case, the certificate issuer Subject is not the same as the certificate > CN subject. If my understanding is correct, TrustSelfSignedStrategy should, > after checking chain.length == 1, also check that both Subject and Issuer > fields are identical. Something like: > > @Override > public boolean isTrusted( > final X509Certificate[] chain, final String authType) throws > CertificateException { > return ( chain.length == 1 && > chain[0].getIssuerX500Principal().equals(chain[0].getSubjectX500Principal())) > } >
I cannot claim to be a PKI specialist but cannot see how anything signed by another cert could possibly have a cert chain with one cert only. Do you think you could generate such a cert with openssl and post it here? Oleg > > > > > > Perhaps it would be clearer for users if the API had a > > TrustAllCertsStrategy, just like a NoopHostnameVerifier > > > > > > > You are welcome to contribute one for 5.0 > > > > Oleg > > > > > > > > David > > > > > > > > > > > > > > > > > > > Le 2 mars 2016 à 07:34, Oleg Kalnichevski <[email protected]> a écrit : > > > > > > > > On Tue, 2016-03-01 at 11:51 -0500, David Duchaine wrote: > > > >> Hello, > > > >> > > > >> just stumbled across a problem with the > > > >> > > > >> org.apache.http.conn.ssl.TrustSelfSignedStrategy.isTrusted( > > > >> final X509Certificate[] chain, final String authType) > > > >> > > > >> 4.4.1 implementation > > > >> > > > >> public boolean isTrusted( > > > >> final X509Certificate[] chain, final String authType) > > throws > > > >> CertificateException { > > > >> return chain.length == 1; > > > >> } > > > >> > > > >> > > > >> Problem was that my client code was communicating with a server which > > had a > > > >> CA signed certificate. The chain length was not equal 1 so isTrusted > > > >> returned false; > > > >> > > > >> > > > >> Even though the javadoc specifically says : > > > >> > > > >> A trust strategy that accepts self-signed certificates as trusted. > > > >> Verification of all other > > > >> * certificates is done by the trust manager configured in the SSL > > context. > > > >> > > > >> Most of the examples found on the Internet use > > TrustSelfSignedStrategy . I > > > >> think people use that one to trust any certificate, signed or not, > > even if > > > >> that would pose a security issue. > > > >> > > > >> > > > >> Do you think it might be appropriate to change the method isTrusted > > so that > > > >> it returns true in any case? > > > >> > > > > > > > > TrustSelfSignedStrategy does exactly what its name implies: it treats > > > > self-signed (no CA) certs, but requires all certs issued by a CA to be > > > > verified as trusted. > > > > > > > > What would be the point in making it trust certificates > > > > indiscriminately? > > > > > > > > Oleg > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] <mailto: > > [email protected]> > > > > For additional commands, e-mail: [email protected] <mailto: > > [email protected]> > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
