Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Date: Wed, 12 Dec 2012 21:53:22 +0000 (UTC)
From: "Claudio Corsi (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Message-ID: <JIRA.12547959.1332604007170.25431.1355349202749@arcas>
In-Reply-To: <JIRA.12547959.1332604007170@arcas>
References: <JIRA.12547959.1332604007170@arcas>
Subject: [jira] [Updated] (AMQ-3785) ActiveMQSslConnectionFactory does not
 detect ssl request in failover URIs when creating transports
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/AMQ-3785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claudio Corsi updated AMQ-3785:
-------------------------------

    Attachment: server.keystore
                client.keystore
                ssltruststore.patch

This patch fixes the original issue that was brought up with here.  

The problem was that the getUrlOrResourceAsStream method would assume that the passed store name was formatted as a url or was available on the classpath.  It does not take into account the possibility that the store was not located in the classpath and that the passed store name was not converted into a url.

This patch fixes this issue. 

Note that the attached stores are copies from the activemq-stomp module.
                
> ActiveMQSslConnectionFactory does not detect ssl request in failover URIs when creating transports
> --------------------------------------------------------------------------------------------------
>
>                 Key: AMQ-3785
>                 URL: https://issues.apache.org/jira/browse/AMQ-3785
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Transport
>    Affects Versions: 5.5.0
>         Environment: Looks global from SVN source but I detected with JDK 1.6.0_31 on Redhat Linux client using AMQ 5.5.0
>            Reporter: Jack Fitch
>            Assignee: Gary Tully
>             Fix For: 5.7.0
>
>         Attachments: ActiveMQFailoverTest.zip, client.keystore, server.keystore, ssltruststore.patch
>
>
> The createTransport method in ActiveMQSslConnectionFactory delegates to the super class if the URI scheme 
> is not ssl. Failover URIs have 'failover' as the URI scheme and so always delegate to the superclass. This causes
> ssl connections that need key or trust stores manipulated by code to hang or fail  as the credentials are not available. 
> Code from  SVN trunk for ActiveMQSslConnectionFactory shows why
>  protected Transport createTransport() throws JMSException {
>         // If the given URI is non-ssl, let superclass handle it.
>         if (!brokerURL.getScheme().equals("ssl")) {
>             return super.createTransport();
>         }
> // !! jackf comment Code below never reached for failover URIs like failover:ssl:... or failover:(tcp:..., ssl...)
> // because the URI Scheme is failover, not ssl.
> // Therefore connections that need a keyManager or trustManager fail
>         try {
>             if (keyManager == null || trustManager == null) {
>                 trustManager = createTrustManager();
>                 keyManager = createKeyManager();
>                 // secureRandom can be left as null
>             }
>             SslTransportFactory sslFactory = new SslTransportFactory();
>             SslContext ctx = new SslContext(keyManager, trustManager, secureRandom);
>             SslContext.setCurrentSslContext(ctx);
>             return sslFactory.doConnect(brokerURL);
>         } catch (Exception e) {
>             throw JMSExceptionSupport.create("Could not create Transport. Reason: " + e, e);
>         }
>     }
>  
> (Vague) Solution: 1) need better pattern match than URI scheme to detect requests for ssl connections. 2) A failover URI is  essentially a list of URIs so multiple ssl transport requests may be in the failover list. A first start is to require that the same key and trust stores are used for all failover connections but you may want to consider allowing customized stores for each of the ssl connections.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira