如何使用相同的HttpClient实例选择客户端证书?

时间:2012-10-16 18:35:40

标签: java ssl ssl-certificate apache-httpclient-4.x truststore

我有一个由多个客户使用的应用程序(其中一个用他/她的客户端证书)。该应用程序应该通过HTTPS与Web服务(使用HttpClient)通信。要在此Web服务中进行身份验证,必须提供客户端证书。如前所述,每个客户端都有不同的客户端证书,我需要使用当前客户端的证书。我有以下代码正在执行所描述的内容。

X509TrustManager trustManager = new X509TrustManager() {

    public void checkClientTrusted(X509Certificate[] xcs, String string) throws CertificateException {
    }

    public void checkServerTrusted(X509Certificate[] xcs, String string) throws CertificateException {
    }

    public X509Certificate[] getAcceptedIssuers() {
        return null;
    }
};
SSLContext sslcontext = SSLContext.getInstance("TLS");
KeyManager[] managers = /* Code that get the current client's KeyManager[] */;

sslcontext.init(managers, trustManager, null);
SSLSocketFactory socketFactory = new SSLSocketFactory(sslcontext);
socketFactory.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

HttpParams params = new BasicHttpParams();
params.setBooleanParameter(ClientPNames.HANDLE_REDIRECTS, true);
HttpClient client = new DefaultHttpClient(params);
Scheme sch = new Scheme("https", socketFactory, 443);

client.getConnectionManager().getSchemeRegistry().register(sch);
HttpPost post = /* Code that get the POST */ 

HttpResponse response = client.execute(post, new BasicHttpContext());

好的,它正在发挥作用。但是有很多线程向这项服务发送请求。有时它会给我一些问题。所以,我发现很多人都说每个应用程序只有一个HttpClient会更好,并且可以这样做:

SchemeRegistry schemeRegistry = new SchemeRegistry();
schemeRegistry.register(new Scheme("http", 80, PlainSocketFactory.getSocketFactory()));
schemeRegistry.register(new Scheme("https", 443, SSLSocketFactory.getSocketFactory()));

PoolingClientConnectionManager cm = new PoolingClientConnectionManager(schemeRegistry);
// Increase max total connection to 200
cm.setMaxTotal(200);
// Increase default max connection per route to 20
cm.setDefaultMaxPerRoute(20);
// Increase max connections for localhost:80 to 50
HttpHost localhost = new HttpHost("localhost", 80);
cm.setMaxPerRoute(new HttpRoute(localhost), 50);

httpClient = new DefaultHttpClient(cm, params);

这样我就有了一个带有连接池的HttpClient。但是,如何使用此方法并为特定请求选择客户端证书?提前谢谢。

编辑:

我会试着解释我为什么要这样做。我们有时遇到问题。服务器停止与Web服务器的通信,并在一段时间后再次开始工作。重要的是要注意在调用webservice之前已经完成了很多处理。因此,有一个池化的Executor可以创建线程来完成所有处理。作业完成后,该线程创建另一个与Web服务通信的线程。因此,第一个线程以超时(thread.join(timeout))连接第二个线程。当第一个线程唤醒时,它会中断尝试与Web服务通信的线程(如果尚未完成)。我不是谁实现了这个,但它应该给完成请求超时。 在我的开发机器中,我创建了一个JMeter测试,它模拟了许多使用此服务的客户端,并连接了JConsole以查看发生了什么。在完成300个任务(其中一些失败)后,Executor池创建的线程死亡。但很多线程一直活着,他们在10分钟后就死了。当我查看堆栈跟踪时,我看到它与HttpClient有关。然后,我开始搜索并发现人们说最好只为整个应用程序使用一个HttpClient,使其成为连接池。 我认为HttpClient在搜索要连接的端口时是锁定的,并且被第一个线程中断。然后,它以某种方式锁定了很长时间。

编辑:

这就是我在JConsole中看到的。这一次,我只启动了100个任务,并且在这种状态下有15个线程:

Name: Thread-228
State: RUNNABLE
Total blocked: 0  Total waited: 0

Stack trace: 
 java.net.SocketInputStream.socketRead0(Native Method)
java.net.SocketInputStream.read(SocketInputStream.java:129)
com.sun.net.ssl.internal.ssl.InputRecord.readFully(InputRecord.java:293)
com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:331)
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:798)
   - locked java.lang.Object@7c1975
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1138)
   - locked java.lang.Object@16b53a6
com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1165)
com.sun.net.ssl.internal.ssl.SSLSocketImpl.getSession(SSLSocketImpl.java:1916)
org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:91)
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:692)
org.apache.http.conn.scheme.SchemeSocketFactoryAdaptor.connectSocket(SchemeSocketFactoryAdaptor.java:65)
org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:640)
org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:479)
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
sun.reflect.GeneratedMethodAccessor3671.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229)
org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:128)
br.com.fibonacci.webservice.InvocacaoDeServico$_monteChamada_closure8.doCall(InvocacaoDeServico.groovy:441)
sun.reflect.GeneratedMethodAccessor3667.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
br.com.fibonacci.webservice.InvocacaoDeServico$_monteChamada_closure8.call(InvocacaoDeServico.groovy)
sun.reflect.GeneratedMethodAccessor3662.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.call(PogoMetaMethodSite.java:63)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124)
br.com.fibonacci.ChamadaComTimeout$_execute_closure1.doCall(ChamadaComTimeout.groovy:19)
sun.reflect.GeneratedMethodAccessor3657.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:266)
org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:51)
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:150)
br.com.fibonacci.ChamadaComTimeout$_execute_closure1.doCall(ChamadaComTimeout.groovy)
sun.reflect.GeneratedMethodAccessor3655.invoke(Unknown Source)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
java.lang.reflect.Method.invoke(Method.java:597)
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:234)
groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1061)
groovy.lang.ExpandoMetaClass.invokeMethod(ExpandoMetaClass.java:910)
groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:892)
groovy.lang.Closure.call(Closure.java:279)
groovy.lang.Closure.call(Closure.java:274)
groovy.lang.Closure.run(Closure.java:355)
java.lang.Thread.run(Thread.java:662)

2 个答案:

答案 0 :(得分:2)

我认为这不可能,因为IMO没有任何意义。
重新使用纯文本连接是有意义的,但用于经过身份验证的加密连接。
每个连接都属于一个用户,应该根据SSL参数终止,而不是在用户之间重用。

答案 1 :(得分:0)

我发现这篇很棒的博文http://javaeesupportpatterns.blogspot.com.br/2011/04/javanetsocketinputstreamsocketread0.html解释了我的问题。它与HttpClient并没有真正的联系。问题在于超时实现。