On 6/7/16 11:02 AM, Oleg Kalnichevski wrote: > On Tue, 2016-06-07 at 15:45 +0200, Ivan Brencsics wrote: >> Hi Oleg, >> >> Thanks for your answer, maybe I did not explain clearly our use case. We >> need to call several external systems over HTTP, and every system has >> different requirements. All need TLS, but some need client certificate, >> others not, some of them needs a certain client certificate that differs >> from others, some of them wants to exclude certain protocols and cipher >> suites. My idea is that we need as many SSLConnectionFactiories as many >> external systems. This is what I cant achieve now with a single HttpClient >> / PoolingHttpClientConnectionManager. The PoolingHttpClientConnectionManager >> can be given a single HTTPS connection factory, but I would need multiple >> different factories I suspect. Am I wrong with this? >> > No need for multiple factories. A single factory should be perfectly > capable of setting different SSL contexts based on hostname / DNS / > HttpContext attributes. > > Oleg >
FWIW, as an example, this is actually exactly what we do in OpenSAML/Shibboleth. We have a couple of custom TLS socket factory impls which allow specifying some things on a per-request basis using HttpContext attributes: TLS protocols; TLS cipher suites; hostname verifier; client certificate; and trust engine (our abstraction for how the TLS server certificate is evaluated. http://git.shibboleth.net/view/?p=java-support.git;a=blob;f=src/main/java/net/shibboleth/utilities/java/support/httpclient/TLSSocketFactory.java;hb=HEAD http://svn.shibboleth.net/view/java-opensaml/trunk/opensaml-security-impl/src/main/java/org/opensaml/security/httpclient/impl/SecurityEnhancedTLSSocketFactory.java?view=markup For project API reasons, the client cert and trust engine support is in the second class, which just wraps a "real" TLS socket factory, such as an instance of the first. Thanks, Brent
