Hi Robbie,

The scenario I am talking about was the second one, where I will be using 
distinct client certificates for SSL client-auth to different connections.

Basically, I would like to be able to provide an SSL context down through to 
the connection in a similar way to how other APIs work or as the URL parameters 
allowed in the client for the earlier protocols.

I believe the failover params also used to be available through the connection 
URL, is there an alternate mechanism for specifying these in the AMQP 1.0 
client library?

Thanks for your responses.



--
Matthew Rich

-----Original Message-----
From: Robbie Gemmell [mailto:[email protected]] 
Sent: 04 October 2013 15:51
To: [email protected]
Subject: Re: Specifying SSL information in URL for AMQP 1.0

Do you mean multiple brokers using distinct certificates, or multiple 
connections (toone or many brokers) using distinct client certificates for SSL 
client-auth purposes?

The former would just require adding multiple entries to the configured 
truststore, whereas the latter would obviously require either the ability to 
set distinct keystores or ability to specify which key should be used from 
multiple entries in a single store, which I don't believe the 1.0 client can 
currently do (mainly as its existance came primarily from prototying work 
undertaken during creation of the AMQP 1.0 specification itself).

Robbie

On 4 October 2013 13:59, mrich <[email protected]> wrote:

> Hi Robbie,
>
> Thanks for the clarification, I thought as much (as posted in my 'edited'
> original post), I was just hoping there is some other way of dictating 
> this, which presumably there is not (without creating my own factory I 
> guess)
>
> The problem I have is if you think of a scenario where you need to 
> send messages to multiple queues that are represented by different 
> clients and therefore secured by different certificates meaning I 
> cannot use the global
> (JVM) settings.
>
> Do you believe that the API should provide a way of customising the 
> security information on a per connection/factory basis, which would 
> warrant a jira issue being raised?
>
> Thanks for your patient response.
>
>
>
> --
> View this message in context:
> http://qpid.2158936.n2.nabble.com/Specifying-SSL-information-in-URL-fo
> r-AMQP-1-0-tp7598974p7599000.html Sent from the Apache Qpid users 
> mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected] For 
> additional commands, e-mail: [email protected]
>
>


______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com 
______________________________________________________________________

______________________________________________________________________

The Company gives no warranty as to the accuracy or completeness of electronic 
mail messages sent over the Internet and accepts no responsibility for changes 
made after it was sent. Any opinion expressed in this email may be personal to 
the author, may not necessarily reflect the opinions of the Company or its 
affiliates and may be subject to change without notice. 

The information contained in this communication is confidential and/or 
proprietary business or technical data. If you are not the intended recipient, 
you are hereby notified that any dissemination, copying or distribution of this 
communication, or the taking of any action in reliance on the contents of this 
communication, is strictly prohibited. If you have received this communication 
in error, please immediately notify us electronically by return message, and 
delete or destroy all copies of this communication.

Quicksilva Limited, Reg No 3860799, Incorporated at Companies House, Cardiff.
Registered Office: Langley Gate, Swindon Road, Chippenham, Wiltshire, SN15 5SE. 
 Vat Reg No 762 8082 16. 

______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to