Hello,
I guess it depends on the definition of "verifying session", for
example I was using the TrustStrategy to do (additional) certificate
public key info pinning:
pinnedCertTrust = new PinnedCertTrust("...=");
// this context falls back to system trust material (but first checks pinning)
SSLContext sslcontext = SSLContexts.custom().useProtocol("TLSv1.2")
.loadTrustMateria(pinnedCertTrust).build();
// Allow TLSv1.2 protocol only
SSLConnectionSocketFactory sslsf = new SSLConnectionSocketFactory(sslcontext,
new String[] { "TLSv1.2" },
null,
SSLConnectionSocketFactory.getDefaultHostnameVerifier());
builder.setSSLSocketFactory(sslsf);
If the pin fails it throws a CertificateException, when it suceeds it
returns false (which falls back to doing all normal trust checks in
addition to the pinning).
Gruss
Bernd
Am Mon, 22 Aug 2016 17:09:34 +0200
schrieb Oleg Kalnichevski <[email protected]>:
> On August 22, 2016 2:50:35 PM GMT+02:00, Sachin Nikumbh
> <[email protected]> wrote:
> >Hi Oleg,
> >
> >Thanks for your response. I had thought of using custom
> >HostnameVerifier. However, it only gets called if the default
> >hostname verification fails and that won’t work for me. We need to
> >do the custom verification for the server certificate when the
> >default hostname verification is successful as well.
> >
> >We have an existing code that uses CloseableHttpAsyncClient. We have
> >solved our problem by using a custom SSLIOSessionStrategy,
> >RegistryBuilder and PoolingNHttpClientConnectionManager. Is there any
> >way to use similar technique with the CloseableHttpClient?
> >
> >Thanks
> >Sachin
> >
>
> ConnectionSocketFactory in the classic HttpClient module will give
> you full control over the process of socket initialization. See the
> stock SSL implementation for details and use it as a starting point.
>
> Oleg
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
