2016-03-02 10:18 GMT-05:00 Oleg Kalnichevski <[email protected]>: > 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? > > First, I will try to understand why the chain length received by the isTrusted method is different from server A (CA signed, length == 1) and server B (signed by same CA as A, length == 3)
According to RFC5280, at the end of section4.1.2.4 <https://tools.ietf.org/html/rfc5280#section-4.1.2.4>. Issuer ... Certificate users MUST be prepared to process the issuer distinguished name and subject distinguished name (Section 4.1.2.6 <https://tools.ietf.org/html/rfc5280#section-4.1.2.6>) fields to perform name chaining for certification path validation (Section 6 <https://tools.ietf.org/html/rfc5280#section-6>). Name chaining is performed by matching the issuer distinguished name in one certificate with the subject name in a CA certificate. Rules for comparing distinguished names are specified in Section 7.1 <https://tools.ietf.org/html/rfc5280#section-7.1>. *If the names in the issuer and subject field in a certificate match according to the rules specified in Section 7.1 <https://tools.ietf.org/html/rfc5280#section-7.1>, then the certificate is self-issued.* I will keep you informed of my findings. David > > > > > > > > > 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] > >
