You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Piotr Klimczak (JIRA)" <ji...@apache.org> on 2014/07/30 11:25:39 UTC

[jira] [Commented] (AMQ-5295) HTTPS Network Connector doesn't work with Mutual authentication- HTTPSClientTransport uses wrong SSLSocketFactory

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

Piotr Klimczak commented on AMQ-5295:
-------------------------------------

It looks like it is not the only problem with mutual authentication functionality.
Once SSLSocketFactory is ok, then NullPointerExceptions occurs.
Debugging...

> HTTPS Network Connector doesn't work with Mutual authentication- HTTPSClientTransport uses wrong SSLSocketFactory
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-5295
>                 URL: https://issues.apache.org/jira/browse/AMQ-5295
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Connector
>    Affects Versions: 5.9.0
>         Environment: JBoss Fuse 6.1
>            Reporter: Piotr Klimczak
>              Labels: SSL, TLS, mutualSSL
>   Original Estimate: 16h
>  Remaining Estimate: 16h
>
> HttpsClientTransport is getting wrong SSLSocketFactory.
> The problem is here:
> {code}
>     private SchemeRegistry createSchemeRegistry() {
>         SchemeRegistry schemeRegistry = new SchemeRegistry();
>         try {
>             // register the default socket factory so that it looks at the javax.net.ssl.keyStore,
>             // javax.net.ssl.trustStore, etc, properties by default
>             SSLSocketFactory sslSocketFactory =
>                     new SSLSocketFactory((javax.net.ssl.SSLSocketFactory) javax.net.ssl.SSLSocketFactory.getDefault(),
>                     SSLSocketFactory.BROWSER_COMPATIBLE_HOSTNAME_VERIFIER);
>             schemeRegistry.register(new Scheme("https", getRemoteUrl().getPort(), sslSocketFactory));
>             return schemeRegistry;
>         } catch (Exception e) {
>             throw new IllegalStateException("Failure trying to create scheme registry", e);
>         }
>     }
> {code}
> The problem with that code is, that it never take SSLSocketFactory from spring context. So the one defined in XML is ignored.
> So it's code have to be replaced with:
> {code}
>     private SchemeRegistry createSchemeRegistry() {
>         SchemeRegistry schemeRegistry = new SchemeRegistry();
>         try {
>             // register the default socket factory so that it looks at the javax.net.ssl.keyStore,
>             // javax.net.ssl.trustStore, etc, properties by default
>             SSLSocketFactory sslSocketFactory = createSocketFactory();
>             schemeRegistry.register(new Scheme("https", getRemoteUrl().getPort(), sslSocketFactory));
>             return schemeRegistry;
>         } catch (Exception e) {
>             throw new IllegalStateException("Failure trying to create scheme registry", e);
>         }
>     }
> {code}
> And then new method should be added:
> {code}
>     /**
>      * Creates a new SSL SocketFactory. The given factory will use user-provided
>      * key and trust managers (if the user provided them).
>      *
>      * @return Newly created (Ssl)SocketFactory.
>      * @throws IOException
>      */
>     protected SocketFactory createSocketFactory() throws IOException {
>         if (SslContext.getCurrentSslContext() != null) {
>             SslContext ctx = SslContext.getCurrentSslContext();
>             try {
>                 return ctx.getSSLContext().getSocketFactory();
>             } catch (Exception e) {
>                 throw IOExceptionSupport.create(e);
>             }
>         } else {
>             return SSLSocketFactory.getDefault();
>         }
>     }
> {code}
> This is consistent solution with other transports.
> I will prepare patches and tests for this scenerio.
> Greetings
> Piotr Klimczak



--
This message was sent by Atlassian JIRA
(v6.2#6252)