I will try SSLContext and loadTrustMaterial() and ask any further questions.
Thanks, Mohan On 8 November 2017 at 01:43, Christopher Schultz < [email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Mohan, > > On 11/7/17 6:31 AM, Mohan Radhakrishnan wrote: > > I have imported the server certificate into a new truststore.( not > > cacerts ). with one line of code to set the system property > > javax.net.ssl.trustStrore to point to my truststore. > > You shouldn't do this: you are setting the truststore for the whole > JVM and not just this particular connection. > > Instead, you should write proper Java code to configure your > HttpClient to use your preferred truststore. > > - -chris > > > On 6 November 2017 at 13:36, Bernd Eckenfels > > <[email protected]> wrote: > > > >> Without knowing your code it is hard to tell what is configured. > >> You can implement multiple strategies for server certificate > >> checking (including to ignore the checks or use the default > >> cacerts trust store) > >> > >> Gruss Bernd -- http://bernd.eckenfels.net > >> ________________________________ From: Mohan Radhakrishnan > >> <[email protected]> Sent: Monday, November 6, 2017 > >> 8:48:42 AM To: HttpClient User Discussion Subject: Re: SSL > >> Certificate exceptions and defensive coding > >> > >> Hello, > >> > >> Could you point to some sample ? When I invoke this Https WSDL > >> URL I do get a certificate in the browser. The URL pointing to > >> the SOAP service is also a HTTPS URL. > >> > >> Does this mean that the server presents its certificate to the > >> client which has to trust it ? How does HttpClient know how to > >> trust it without the truststore ? > >> > >> The following is unrelated to my original question but this is > >> what I observe. > >> > >> When I generate JAX-WS classes I need to import the WSDL URL > >> certificate into my trust store and set the system properly. > >> > >> Thanks, Mohan > >> > >> On 5 November 2017 at 22:38, Oleg Kalnichevski <[email protected]> > >> wrote: > >> > >>> 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/SSLConnectionSocketFac > t > >>>>> > >>>>> > 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] > >>> > >>> > >> > > > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAloCE/cdHGNocmlzQGNo > cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFgPXw/7BLYLaYSSGQSWQAbL > k8PV0z1ndN5zSJQv/2Po/hQ5HSWKa9BMO03+41gUAJb2CkpmpfsOHhwQZPoy3tP8 > NIm0wmRmD9BnXoik2AusKTy/KGh9tejrBgF+bYViXEgW/RyHGHHOWvFlBo4YcimX > ZSq42HpJP4+rzy21Sx/Ri3motwBq1ONQgZibTfFF89dTRV4F+IBH74W7Jyg1jLlp > txQTxIUGGKUfA4E69dvwKHw32uY8T9z65lv/ciBhS6i+n5qPQOb4Ry6xPZIAmrCo > qax6emf93q9opLY4ee02mt4Djh+X2BMVL36ryAHfw2JlJNZAmPqB0+cZ8N5KsHxr > ZOrX4sRKfeteVhNV+mCkjMtvWuV+9vxKKWt3v3mh61tLKxk077+g6wuGwG6EiIzm > EWZnG2yVYnUX51O7gonvGAuUfjjPnl4GFRGtxNGit3E5Pa19TONFf4lG6pxDqxza > FiF6HQV+WL6FdiXORSrFM72TXLat/HauyZbIWrQo/bx+S9uCGkEcgXmS7Y+k8J9Q > lTDIA2TmQW4KfPXreVW2OPq4g2mZ798Dd+OtDUAlPlcA83Hl6gqvWF4FygfOrQhF > sLpz4SZdtZNvRfqtzNPkpOnIv0d3FypqaiUZs8jxKiz/Ca6d6jsuJryxhOKrEewo > p2QplkK/JDZCYh3sbiOa3223OK4= > =lWME > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
