You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Matti Aarnio (JIRA)" <ji...@apache.org> on 2017/12/21 16:52:00 UTC
[jira] [Updated] (HTTPCLIENT-1894)
PoolingHttpClientConnectionManager difficulties with client certificate
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matti Aarnio updated HTTPCLIENT-1894:
-------------------------------------
Description:
We run SOAP calls over HTTPS with specific client keypair and certificate attached into communication. We followed tutorial way to create a CloseableHtpClient with customized PoolingHttpClientConnectionManager(), which has a customized Registry<..> instance with appropriately custom constructed SSLSocketFactory instance hooked on our specific client keystore.
However things didn't work as expected. HttpClient kept opening new sockets, and not reusing any.
We created a wrapper class on top of PoolingHttpClientConnectionManager() which logged the received call parameters, and called original function.
Then we saw that {{ConnectionRequest requestConnection(HttpRoute route, Object state)}} was called with {{state = null}}, and that {{void releaseConnection(HttpClientConnection managedConn, Object state, long keepalive, TimeUnit tunit)}} was called with {{state != null}}.
Specifically at release time the state value was HTTPS client certificate Subject in text form, while at request time it was null.
{color:#205081}*So the pool never found any connections returned into pool because lookup criteria did not match the store keys.*{color}
Now that we have a wrapper class on top of {{PoolingHttpClientConnectionManager}} we could simply force the state to be null both on request and on release time, and session reuse works.
We did not use {{HttpClientContext.setUserToken(Object val)}} before debugging this issue, nor are using any afterwards; during debug we observed that {{requestConnection()}} had our supplied value at {{state}}, and {{releaseConnection}} had null. (Opposite to what it did show without UserToken parameter.)
So: Why does releaseConnection() time supply a state value with TLS client keystore certificate subject value when requestConnection() has state=null, and if I supply requestConnection() with non-null state value, then releaseConnection() has null state value?
There are no pool reuse problems in HTTP URLs, only on HTTPS URLs with client certificate being used.
was:
We run SOAP calls over HTTPS with specific client keypair and certificate attached into communication. We followed tutorial way to create a CloseableHtpClient with customized PoolingHttpClientConnectionManager(), which has a customized Registry<..> instance with appropriately custom constructed SSLSocketFactory instance hooked on our specific client keystore.
However things didn't work as expected. HttpClient kept opening new sockets, and not reusing any.
We created a wrapper class on top of PoolingHttpClientConnectionManager() which logged the received call parameters, and called original function.
Then we saw that {{ConnectionRequest requestConnection(HttpRoute route, Object state)}} was called with {{state = null}}, and that {{void releaseConnection(HttpClientConnection managedConn, Object state, long keepalive, TimeUnit tunit)}} was called with {{state != null}}.
Specifically at release time the state value was HTTPS client certificate Subject in text form, while at request time it was null.
{color:#205081}*So the pool never found any connections returned into pool because lookup criteria did not match the store keys.*{color}
Now that we have a wrapper class on top of {{PoolingHttpClientConnectionManager}} we could simply force the state to be null both on request and on release time, and session reuse works.
We did not use {{HttpClientContext.setUserToken(Object val)}} before debugging this issue, nor are using any afterwards; during debug we observed that {{requestConnection()}} had our supplied value at {{state}, and {{releaseConnection}} had null. (Opposite to what it did show without UserToken parameter.)
So: Why does releaseConnection() time supply a state value with TLS client keystore certificate subject value when requestConnection() has state=null, and if I supply requestConnection() with non-null state value, then releaseConnection() has null state value?
There are no pool reuse problems in HTTP URLs, only on HTTPS URLs with client certificate being used.
> PoolingHttpClientConnectionManager difficulties with client certificate
> -----------------------------------------------------------------------
>
> Key: HTTPCLIENT-1894
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1894
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 4.5.4
> Environment: Linux x86-64 Oracle JRE
> Reporter: Matti Aarnio
>
> We run SOAP calls over HTTPS with specific client keypair and certificate attached into communication. We followed tutorial way to create a CloseableHtpClient with customized PoolingHttpClientConnectionManager(), which has a customized Registry<..> instance with appropriately custom constructed SSLSocketFactory instance hooked on our specific client keystore.
> However things didn't work as expected. HttpClient kept opening new sockets, and not reusing any.
> We created a wrapper class on top of PoolingHttpClientConnectionManager() which logged the received call parameters, and called original function.
> Then we saw that {{ConnectionRequest requestConnection(HttpRoute route, Object state)}} was called with {{state = null}}, and that {{void releaseConnection(HttpClientConnection managedConn, Object state, long keepalive, TimeUnit tunit)}} was called with {{state != null}}.
> Specifically at release time the state value was HTTPS client certificate Subject in text form, while at request time it was null.
> {color:#205081}*So the pool never found any connections returned into pool because lookup criteria did not match the store keys.*{color}
> Now that we have a wrapper class on top of {{PoolingHttpClientConnectionManager}} we could simply force the state to be null both on request and on release time, and session reuse works.
> We did not use {{HttpClientContext.setUserToken(Object val)}} before debugging this issue, nor are using any afterwards; during debug we observed that {{requestConnection()}} had our supplied value at {{state}}, and {{releaseConnection}} had null. (Opposite to what it did show without UserToken parameter.)
> So: Why does releaseConnection() time supply a state value with TLS client keystore certificate subject value when requestConnection() has state=null, and if I supply requestConnection() with non-null state value, then releaseConnection() has null state value?
> There are no pool reuse problems in HTTP URLs, only on HTTPS URLs with client certificate being used.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org