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) Perhaps it would be clearer for users if the API had a TrustAllCertsStrategy, just like a NoopHostnameVerifier 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]>
