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()))
}
>
> > 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]
>
>
