hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (HTTPCLIENT-1091) Regression: 2 way authentication with SSL doesn't work in versions 4.1.x, used to work with 4.0.x
Date Mon, 16 May 2011 15:41:47 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13034065#comment-13034065
] 

Oleg Kalnichevski edited comment on HTTPCLIENT-1091 at 5/16/11 3:40 PM:
------------------------------------------------------------------------

Actually two-way SSL works fine for me as long as the SSL context is properly initialized
with trust and private material (see the code snippet below)

---
        KeyStore truststore = KeyStore.getInstance("jks");
        FileInputStream instream1 = new FileInputStream(new File("clientTrustStore.jks"));
        try {
            truststore.load(instream1, "password".toCharArray());
        } finally {
            instream1.close();
        }
        KeyStore keystore = KeyStore.getInstance("pkcs12");
        FileInputStream instream2 = new FileInputStream(new File("clientKeyStore.p12"));
        try {
            keystore.load(instream2, "password".toCharArray());
        } finally {
            instream2.close();
        }
        SSLSocketFactory sslf = new SSLSocketFactory("TLS", keystore, "password", truststore,
null,
                SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
        DefaultHttpClient client = new DefaultHttpClient();
        client.getConnectionManager().getSchemeRegistry().register(new Scheme("https", 443,
sslf));
        HttpGet method = new HttpGet("https://localhost:8443");
        HttpResponse resp = client.execute(method);

        HttpEntity entity = resp.getEntity();
        String data = EntityUtils.toString(entity, "UTF-8");
        System.out.println(data);
---

SSLSocketFactory in 4.0.x makes use of  HttpsURLConnection#getDefaultSSLSocketFactory() in
order to obtain an instance of system SSL socket factory configured with the default trust
and private material. This creates a dependency on a class that can potentially be Java runtime
specific, which I would rather prefer to avoid. This dependency was removed in the 4.1.x branch.
Per default SSLSocketFactory in 4.1.x relies on the SSLContext initialization routine to bootstrap
itself. Curiously enough, SSLContext appears to pick up the default trust material specified
with system properties while ignoring the default private material. 

I am very tempted to close this issue as WONTFIX. Could you live with that?

Oleg



      was (Author: olegk):
    Actually two SSL works fine for me as long as the SSL context is properly initialized
with trust and private material (see the code snippet below)

---
        KeyStore truststore = KeyStore.getInstance("jks");
        FileInputStream instream1 = new FileInputStream(new File("clientTrustStore.jks"));
        try {
            truststore.load(instream1, "password".toCharArray());
        } finally {
            instream1.close();
        }
        KeyStore keystore = KeyStore.getInstance("pkcs12");
        FileInputStream instream2 = new FileInputStream(new File("clientKeyStore.p12"));
        try {
            keystore.load(instream2, "password".toCharArray());
        } finally {
            instream2.close();
        }
        SSLSocketFactory sslf = new SSLSocketFactory("TLS", keystore, "password", truststore,
null,
                SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
        DefaultHttpClient client = new DefaultHttpClient();
        client.getConnectionManager().getSchemeRegistry().register(new Scheme("https", 443,
sslf));
        HttpGet method = new HttpGet("https://localhost:8443");
        HttpResponse resp = client.execute(method);

        HttpEntity entity = resp.getEntity();
        String data = EntityUtils.toString(entity, "UTF-8");
        System.out.println(data);
---

SSLSocketFactory in 4.0.x branch makes use of  HttpsURLConnection#getDefaultSSLSocketFactory()
in order to obtain an instance of system SSL socket factory configured with the default trust
and private material. This creates a dependency on a class that can potentially be Java runtime
specific, which I would rather prefer to avoid. This dependency was removed in the 4.1.x branch.
Per default SSLSocketFactory in 4.1.x relies on the SSLContext initialization routine to bootstrap
itself. Curiously enough, SSLContext appears to pick up the default trust material specified
with system properties while ignoring the default private material. 

I am very tempted to close this issue as WONTFIX. Could you live with that?

Oleg


  
> Regression: 2 way authentication with SSL doesn't work in versions 4.1.x, used to work
with 4.0.x
> -------------------------------------------------------------------------------------------------
>
>                 Key: HTTPCLIENT-1091
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1091
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient
>    Affects Versions: 4.1.1
>            Reporter: Yuri Manusov
>         Attachments: ClientConnectionTest.java, clientKeyStore.p12, clientTrustStore.jks,
openSSLCertsCreation.bat, server.xml, serverKeyStore.jks
>
>
> Tried to create an SSL tunnel with two way authentication, was able to do that with versions
4.0.1 and 4.0.3, but in versions 4.1 and 4.1.1 I get the exception: 
> Exception in thread "main" javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
>         at com.sun.net.ssl.internal.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:352)
>         at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:128)
>         at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:390)
>         at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:148)
>         at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149)
>         at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121)
>         at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:561)
>         at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415)
>         at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820)
>         at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754)
>         at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:732)
>         at ClientConnectionTest.main(ClientConnectionTest.java:38)
> the creation of the SSL certificates was done using open ssl and java keytool (script
will be attached in openSSLCertsCreation.bat).
> as a client I've used a simple java client (will attach ClientConnectionTest.java)
> as a server Tomcat was used, and configured to allow ssl communication with 2 way authentication
(clientAuth="true").

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message