On Sun, 2017-11-05 at 08:41 +0530, Mohan Radhakrishnan wrote:
> I do have a trustore into which I have imported the server
> certificate. I
> set a system property and use it.
>
> System.setProperty("javax.net.ssl.trustStrore", "trustStore");
>
> JSSE should be able to use it. I think. RIght ? Don't see a problem
> at this
> time. Just getting some clarifications.
>
HttpClient does not take system properties into account by default. You
need to explicitly instruct to do so when building HttpClient
instances.
Oleg
> Thanks,
> Mohan
>
> On 5 November 2017 at 03:28, Bindul Bhowmik <[email protected]>
> wrote:
>
> > Mohan,
> >
> > On Sat, Nov 4, 2017 at 6:01 AM, Mohan Radhakrishnan
> > <[email protected]> wrote:
> > > Hi,
> > >
> > >
> >
> > Let me start by mentioning that Http Client does not implement its
> > own
> > cyrpto algorithms or SSL/TLS protocols. It relies on the underlying
> > Java JSSE implementation to create secure sockets. And unless you
> > have
> > plugged in an alternate JSSE provider, you are using the JSSE
> > implementation packaged with your JRE. Having said that, Http
> > Client
> > does allow some customization to the secure socket creation process
> > using SSLConnectionSocketFactory [1]. This allows you to use an
> > alternate trust store, host name verifier, etc.. The latter being
> > especially valuable during development/testing, but should not be
> > used
> > in production IMO. To see how you can customize the SSL socket
> > creation, please read the 'Connection management' chapter in the
> > Http
> > Client tutorial [2].
> >
> > > I am invoking a HTTPS SOAP service and this is what I
> > > think is
> > > happening. It is one-way SSL. The JSSE implementation
> > > automagically adds
> >
> > it
> > > to the client's truststore and ensures that the SOAP call is
> > > successful.
> >
> > I am not sure that is accurate. If the server you are targeting
> > uses a
> > certificate signed by one of the trusted CAs (or a CA signed by a
> > trusted CA) in your trust store, the secure socket will be
> > established. The client does not alter the trust store
> > automagically,
> > unless you have done it yourself, or are using a custom trust store
> > (other than say the cacerts that ships with Oracle JRE).
> >
> > >
> > > This question is based on this assumption.
> > > When I read
> > > https://www.ssl.com/guide/ssl-best-practices-a-quick-and-dirty-gu
> > > ide/
> >
> > there
> > > are various SSL exceptions and checks that
> > > are required. I code the client. How do I trap the various
> > > exceptions ?
> > > Which list of exceptions should I use for SSL ?
> >
> > I am not sure I understand the question, but if you need to catch
> > all
> > exceptions, see the JSSE Reference Guide [3] on exceptions that can
> > come from the SSL context. I guess the most important one will be
> > javax.net.ssl.SSLException and its sub-classes. As far as I can
> > tell,
> > HC adds org.apache.http.conn.ssl.SSLInitializationException and of
> > course most connect methods can throw IOException.
> >
> >
> > >
> > > How do I know the the HttpClient uses the latest security patches
> > > in my
> >
> > JDK
> > > 8 ? It should automatically be secure. Right ?
> >
> > As I noted above, HC is using the configured or default JSSE
> > implementation in your JRE. If that is patched, you will be as
> > secure
> > as that.
> >
> > >
> > > Thanks,
> > > Mohan
> >
> > Regards,
> > Bindul
> >
> > [1] https://hc.apache.org/httpcomponents-client-ga/
> > httpclient/apidocs/org/apache/http/conn/ssl/SSLConnectionSocketFact
> > ory.
> > html
> > [2] http://hc.apache.org/httpcomponents-client-ga/tutorial/html/
> >
> > -----------------------------------------------------------------
> > ----
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> > g
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
