Return-Path: 
 <commits-return-18518-apmail-activemq-commits-archive=activemq.apache.org@activemq.apache.org>
X-Original-To: apmail-activemq-commits-archive@www.apache.org
Delivered-To: apmail-activemq-commits-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id E5CDB9514
	for <apmail-activemq-commits-archive@www.apache.org>;
 Wed,  4 Apr 2012 18:59:40 +0000 (UTC)
Received: (qmail 16041 invoked by uid 500); 4 Apr 2012 18:59:40 -0000
Delivered-To: apmail-activemq-commits-archive@activemq.apache.org
Received: (qmail 16020 invoked by uid 500); 4 Apr 2012 18:59:40 -0000
Mailing-List: contact commits-help@activemq.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:commits-help@activemq.apache.org>
List-Unsubscribe: <mailto:commits-unsubscribe@activemq.apache.org>
List-Post: <mailto:commits@activemq.apache.org>
List-Id: <commits.activemq.apache.org>
Reply-To: dev@activemq.apache.org
Delivered-To: mailing list commits@activemq.apache.org
Received: (qmail 16013 invoked by uid 99); 4 Apr 2012 18:59:40 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Apr 2012 18:59:40 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=5.0
	tests=ALL_TRUSTED,T_RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Apr 2012 18:59:39 +0000
Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116])
	by hel.zones.apache.org (Postfix) with ESMTP id 7BCA0358DCC
	for <commits@activemq.apache.org>; Wed,  4 Apr 2012 18:59:19 +0000 (UTC)
Date: Wed, 4 Apr 2012 18:59:19 +0000 (UTC)
From: "Hiram Chirino (Updated) (JIRA)" <jira@apache.org>
To: commits@activemq.apache.org
Message-ID: 
 <1155699839.13353.1333565959508.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <535914314.2312.1333233744988.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (APLO-178) Using key_alias= causes all SSL
 connects to fail
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
X-Virus-Checked: Checked by ClamAV on apache.org


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

Hiram Chirino updated APLO-178:
-------------------------------

    Affects Version/s:     (was: wish-list)
             Assignee: Hiram Chirino
    
> Using key_alias= causes all SSL connects to fail
> ------------------------------------------------
>
>                 Key: APLO-178
>                 URL: https://issues.apache.org/jira/browse/APLO-178
>             Project: ActiveMQ Apollo
>          Issue Type: Bug
>          Components: apollo-broker
>         Environment: Ubuntu 11.01, Java OpenJDK Runtime Environment (IcedTea6 1.11pre) (6b23~pre11-0ubuntu1.11.10.2) OpenJDK 64-Bit Server VM (build 20.0-b11, mixed mode)
> apache-apollo-99-trunk-20120328.201231-9-unix-distro.tar.gz
>            Reporter: Guy Allard
>            Assignee: Hiram Chirino
>             Fix For: 1.2
>
>         Attachments: log_no_key_alias.txt, log_with_key_alias.txt
>
>
> After adding 'key_alias=' to the 'key_storage' element, all attempts to connect using SSL fail.
> The only thing I see in connection.log is a connect/disconnect sequence.  Log files apollo.log and security.log show nothing.  I see no real errors in Apollo logs.
> The client gets only:
> Connection reset by peer
> I am running with:
> - the Ruby stomp gem 1.2.2 client
> - <authentication enabled="false"/>
> - default login.config
> - client_auth= not specified (defaulted)
> The alias name is correct I believe:
> apollo@tjjackson:~/my-broker-snap/etc$ grep servertj apollo.xml
>   <key_storage file="${apollo.base}/etc/keystore" password="password" key_password="password" key_alias="servertj" />
> and:
> apollo@tjjackson:~/my-broker-snap/etc$ keytool -list -keystore keystore -storepass password
> Keystore type: JKS
> Keystore provider: SUN
> Your keystore contains 2 entries
> clienttjca, Mar 31, 2012, PrivateKeyEntry, 
> Certificate fingerprint (MD5): FD:F8:2F:94:5F:F2:55:2C:B9:C7:E6:EA:CA:18:52:6C
> servertj, Mar 31, 2012, PrivateKeyEntry, 
> Certificate fingerprint (MD5): F2:F3:89:68:4D:EF:46:EB:23:50:57:76:0B:01:58:58
> So, the store has two entries:
> 1) A server cert
> 2) A Client CA cert (signs all client certs)
> Simply removing key_alias= allows at least some SSL functionality to work.
> Let me know what I can do to assist, docs etc., but key_alias= seems to be ........ not functional in general.
> Regards, Guy

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira