You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Robbie Gemmell <ro...@gmail.com> on 2016/04/04 16:10:57 UTC
Re: 2-WAY SSL Authentication in Proton-J and Dispatch Router
Hi Jack,
This isn't something I had tried before, but I was able to establish a
connecting using the master/0.13.0-SNAPSHOT proton-j reactor and send
messages to a 6.0.x/6.0.2-SNAPSHOT Qpid Java broker that was
configured to require SSL client certs and use the EXTERNAL SASL
mechanism (I didn't have a Dispatch set up appropriately and that was
easier for me, plus the issue described seemed to be client-side).
I had to make the following changes to the existing Send example to
add a required dependency, actually set where the sender is attaching,
change the sasl mech, and configure use of ssl plus provide the
cert/trust details:
http://pastebin.com/TR5azYFR
I notice that the C code you attached to the JIRA (PROTON-1168 for
interested folks) is actually using Messenger with proton-c, and not
the Reactor as mentioned here for proton-j. I'm not sure if your Java
code is actually doing the same since you didn't include it, but that
isn't something I have tried either in any case. I do seem to recall
previous discussion around proton-c Messenger that it isn't actually
possible to set the particular sasl mechanism with Messenger (though
that would presumably be a separate issue from the one the Dispatch
logs suggest occurred, of not sending a cert as requested/required).
Robbie
On 31 March 2016 at 18:02, Gibson, Jack <ja...@paypal.com.invalid> wrote:
> Hello -
>
> We are leveraging proton-j via the reactor framework and noticed a discrepancy between proton-c and proton-j. With proton-c, we are able to establish 2-way authentication via SSL but with proton-j that is unsuccessful. We opened a JIRA on this yesterday but figured we'd ping the lists as well.
>
> Below is the output from our test connecting to the dispatch router configured for 2-way SSL auth.
>
>
> 1.
> 2. Client Error Message: from the log file
> * AMQP framing error
> * EventImpl{type=TRANSPORT_ERROR, context=TransportImpl [_connectionEndpoint=org.apache.qpid.proton.engine.impl.ConnectionImpl@6ef351a0, org.apache.qpid.proton.engine.impl.TransportImpl@44c213d9]}
> 3. Server Error Message: from the log file
> *
>
> =64, totalFreeToHeap=0, transferBatchSize=64, type=org.apache.qpid.dispatch.allocator, typeName=qd_timer_t, typeSize=56)
>
> Wed Mar 30 12:00:47 2016 AGENT (info) Activating management agent on $management
>
> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address Registered: $management
>
> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address Registered: $management
>
> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity: FixedAddressEntity(bias=closest, fanout=single, identity=fixedAddress/0, name=fixedAddress/0, prefix=/, type=org.apache.qpid.dispatch.fixedAddress)
>
> Wed Mar 30 12:00:47 2016 ROUTER (info) Configured Address: prefix=/ phase=0 fanout=QD_SCHEMA_FIXEDADDRESS_FANOUT_SINGLE bias=QD_SCHEMA_FIXEDADDRESS_BIAS_CLOSEST
>
> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity: ListenerEntity(addr=0.0.0.0, authenticatePeer=True, certDb=/home/vsharda/protected/pprootca_cert.pem, certFile=/home/vsharda/protected/generic_cert.pem, identity=listener/0.0.0.0:20009, idleTimeoutSeconds=16, keyFile=/home/vsharda/protected/generic_key.pem, maxFrameSize=65536, name=listener/0.0.0.0:20009, password=pn2.GmdXmkKv.X7fPq.oYDFj8Cs, port=20009, requireEncryption=True, requireSsl=True, role=normal, saslMechanisms=EXTERNAL, stripAnnotations=both, type=org.apache.qpid.dispatch.listener)
>
> Wed Mar 30 12:00:47 2016 CONN_MGR (info) Configured Listener: 0.0.0.0:20009 proto=any role=normal
>
> Wed Mar 30 12:00:47 2016 SERVER (trace) Listening on 0.0.0.0:20009
>
> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity: ConsoleEntity(identity=console/0, name=console/0, type=org.apache.qpid.dispatch.console, wsport=5673)
>
> Wed Mar 30 12:00:47 2016 SERVER (info) Operational, 4 Threads Running
>
> Wed Mar 30 12:01:06 2016 SERVER (debug) Accepting incoming connection from 10.225.90.106:51196 to 0.0.0.0:20009
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) Configuring SSL on incoming connection from 10.225.90.106:51196 to 0.0.0.0:20009
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Server SSL socket created.
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:SSL/TLS connection detected
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl( data size=162 )
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Wrote 162 bytes to BIO Layer, 0 left over
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Detected read-blocked
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl() returning 162
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Read 3651 bytes from BIO Layer
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl() returning 3651
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl() returning 0
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl() returning 0
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl() returning 0
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl() returning 0
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl( data size=205 )
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Wrote 205 bytes to BIO Layer, 0 left over
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:ERROR amqp:connection:framing-error SSL Failure: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]: <- EOS
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]: -> EOS
>
> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:SSL socket freed.
>
> Thanks,
>
> Jack
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: 2-WAY SSL Authentication in Proton-J and Dispatch Router
Posted by "Powar, Suraj" <sp...@paypal.com.INVALID>.
Thanks for sharing the information. We are in process of re-testing the SSL setup with proton-0.13.0 SNAPSHOT with a new Server setup. Will update you with further findings. Thanks!
Regards,
Suraj Powar
On 4/8/16, 4:18 AM, "Robbie Gemmell" <ro...@gmail.com> wrote:
>I posted a copy of broker and client side ssl trace logs (from using
>-Djavax.net.debug=ssl) when running the code, plus a screenshot from
>wireshark showing the client cert being sent. They are attached to the
>JIRA, specifically:
>https://issues.apache.org/jira/secure/attachment/12797708/ssl_logs1.tar.gz
>
>I think it would be useful if you look at the ssl trace logging from
>your attempts for any client side errors. Given the logging from
>Dispatch seems to be indicating a problem where client didnt send a
>certificate, I would probably expect to see something in there about
>why it didn't/couldn't.
>
>Robbie
>
>On 7 April 2016 at 18:53, Powar, Suraj <sp...@paypal.com> wrote:
>> Thanks for the response with the details. But the below information is not different than what you provided earlier and we updated our code as per your guidance and still got the same SSL certificate error.
>>
>>
>> Note - all the SSL cert/keys are configured correctly, we tested the connectivity using OPENSSL and everything works as expected. The 1 way auth works as well, however the moment we enable 2 way auth with our Java client using reactor libraries we see SSL errors. Is it possible for you to share your SSL test logs with 2 way authentication working with your sample code?
>>
>>
>>
>> Regards,
>> Suraj Powar
>>
>>
>>
>>
>>
>>
>>
>>
>> On 4/7/16, 3:38 AM, "Robbie Gemmell" <ro...@gmail.com> wrote:
>>
>>>Hi Suraj,
>>>
>>>I previously attached the code I used to the JIRA Jack raised for this
>>>(https://issues.apache.org/jira/browse/PROTON-1168) as mentioned in my
>>>earlier reply. The file itself is at
>>>https://issues.apache.org/jira/secure/attachment/12797022/PROTON-1168_reactor_ssl.patch.
>>>As I said, I don't think the fact I was using 0.13.0-SNAPSHOT should
>>>make any difference here.
>>>
>>>I used the test SSL resources from our JMS client build
>>>(https://github.com/apache/qpid-jms/tree/master/qpid-jms-client/src/test/resources)
>>>with the code, specifically the broker-jks.keystore +
>>>broker-jks.truststore for the 6.0.2-SNAPSHOT Java broker I was using,
>>>and then for the reactor client I used client.crt + ca.crt and a
>>>client-private-key.pem file created by extracting the key from
>>>client-pkcs12.keystore with openssl (I think by doing this: openssl
>>>pkcs12 -nocerts -passin pass:password -in client-pkcs12.keystore
>>>-passout pass:password -out client-private-key.pem). The files/keys
>>>that use passwords all have it set as "password".
>>>
>>>Regarding your off-list follow-up to your mail, yes the list address
>>>you used seems correct (ignoring the c&p error) but obviously the mail
>>>did not arrive. What error did you actually get back?
>>>
>>>Robbie
>>>
>>>On 7 April 2016 at 00:41, Powar, Suraj <sp...@paypal.com> wrote:
>>>> Hi All,
>>>>
>>>> So, we have tried to implement the proton-J 0.13.0 and still unable to successfully test the 2-way SSL with the reactor code.
>>>>
>>>> Attached is the screenshot of the server logs where you can see SSL error and below is the code snapshot where we are init SSL.
>>>>
>>>>
>>>> //Code for SSL Initialization
>>>> private void initSSL(Connection cnx) {
>>>> SslDomain sslDomain = SslDomain.Factory.create();
>>>> sslDomain.setCredentials(this.container.getCertificateFilePath(),
>>>> this.container.getPrivateKeyFilePath(),
>>>> this.container.getPassword());
>>>> sslDomain.setTrustedCaDb(this.container.getCaCertFilePath());
>>>> sslDomain.setPeerAuthentication(VerifyMode.VERIFY_PEER);
>>>> sslDomain.init(Mode.CLIENT);
>>>> cnx.getTransport().sasl().setMechanisms("EXTERNAL");
>>>> System.out.println("SSL Domain is " + sslDomain.toString());
>>>> cnx.getTransport().ssl(sslDomain);
>>>>
>>>> logger.debug("SSL initialization complete!");
>>>> }
>>>>
>>>>
>>>>
>>>> Is there a possibility you could share a working sample reactor code using Proton-J 0.13.0?
>>>>
>>>>
>>>> Regards,
>>>> Suraj Powar
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 4/5/16, 11:51 AM, "Gibson, Jack" <ja...@paypal.com> wrote:
>>>>
>>>>>+user list
>>>>>
>>>>>
>>>>>CC'everyone else
>>>>>
>>>>>On 4/5/16, 12:05 PM, "Powar, Suraj" <sp...@paypal.com> wrote:
>>>>>
>>>>>>Hi,
>>>>>>
>>>>>>Yes we are using proton J reactor code. We updated the maven dependency
>>>>>>to include the 0.13 version however we got the same result. It will
>>>>>>helpful if you can share some sample code with proton J with 2 way SSL
>>>>>>working. I will check the link again, our internal network may be
>>>>>>blocking the link.
>>>>>>
>>>>>>
>>>>>>Regards,
>>>>>>Suraj
>>>>>>
>>>>>>Sent from my iPhone
>>>>>>
>>>>>>> On Apr 5, 2016, at 1:51 AM, Robbie Gemmell <ro...@gmail.com>
>>>>>>>wrote:
>>>>>>>
>>>>>>> Hi Suraj
>>>>>>>
>>>>>>> The link is just a public pastebin, there aren't any restrictions on
>>>>>>> it that I can alter. It works for me on a couple different
>>>>>>> networks/devices, and the view count suggests it does for others too.
>>>>>>> I have posted the contents as a patch on the JIRA in case you still
>>>>>>> cant access it.
>>>>>>>
>>>>>>> I wasn't suggesting the 0.13.0-SNAPSHOT build would fix the issue you
>>>>>>> are seeing (there aren't any related changes in it that I'm aware of),
>>>>>>> just detailing what I used. As mentioned in my reply, it isn't clear
>>>>>>> whether I even used the same component you have since the thread
>>>>>>> mentioned the proton-j Reactor (which is what I used) however it turns
>>>>>>> out the C code actually uses Messenger.
>>>>>>>
>>>>>>> If you keep discussion on the list (or JIRA) then other people can see
>>>>>>> it too, and perhaps respond such as helping with the pastebin link
>>>>>>> contents earlier.
>>>>>>>
>>>>>>> Robbie
>>>>>>>
>>>>>>>> On 4 April 2016 at 22:41, Powar, Suraj <sp...@paypal.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> So, we tried to run the 2 way SSL tests again using the 0.13 proton J
>>>>>>>>library and still getting the same error.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Enclosed error image attachment
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Suraj Powar
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 4/4/16, 2:17 PM, "Powar, Suraj" <sp...@paypal.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Robbie,
>>>>>>>>>
>>>>>>>>> The link provided below - http://pastebin.com/TR5azYFR is not
>>>>>>>>>accessible. Can you please provide access to this link so we can look
>>>>>>>>>at the client code that you changed to established 2 way ssl?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Suraj Powar
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 4/4/16, 10:26 AM, "Gibson, Jack" <ja...@paypal.com> wrote:
>>>>>>>>>>
>>>>>>>>>> HmmmŠ shall discuss a bit more. Also, do we have the java/reactor
>>>>>>>>>>code :)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On 4/4/16, 9:10 AM, "Robbie Gemmell" <ro...@gmail.com>
>>>>>>>>>>>wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Jack,
>>>>>>>>>>>
>>>>>>>>>>> This isn't something I had tried before, but I was able to
>>>>>>>>>>>establish a
>>>>>>>>>>> connecting using the master/0.13.0-SNAPSHOT proton-j reactor and
>>>>>>>>>>>send
>>>>>>>>>>> messages to a 6.0.x/6.0.2-SNAPSHOT Qpid Java broker that was
>>>>>>>>>>> configured to require SSL client certs and use the EXTERNAL SASL
>>>>>>>>>>> mechanism (I didn't have a Dispatch set up appropriately and that
>>>>>>>>>>>was
>>>>>>>>>>> easier for me, plus the issue described seemed to be client-side).
>>>>>>>>>>>
>>>>>>>>>>> I had to make the following changes to the existing Send example to
>>>>>>>>>>> add a required dependency, actually set where the sender is
>>>>>>>>>>>attaching,
>>>>>>>>>>> change the sasl mech, and configure use of ssl plus provide the
>>>>>>>>>>> cert/trust details:
>>>>>>>>>>>
>>>>>>>>>>> http://pastebin.com/TR5azYFR
>>>>>>>>>>>
>>>>>>>>>>> I notice that the C code you attached to the JIRA (PROTON-1168 for
>>>>>>>>>>> interested folks) is actually using Messenger with proton-c, and not
>>>>>>>>>>> the Reactor as mentioned here for proton-j. I'm not sure if your
>>>>>>>>>>>Java
>>>>>>>>>>> code is actually doing the same since you didn't include it, but
>>>>>>>>>>>that
>>>>>>>>>>> isn't something I have tried either in any case. I do seem to recall
>>>>>>>>>>> previous discussion around proton-c Messenger that it isn't actually
>>>>>>>>>>> possible to set the particular sasl mechanism with Messenger (though
>>>>>>>>>>> that would presumably be a separate issue from the one the Dispatch
>>>>>>>>>>> logs suggest occurred, of not sending a cert as requested/required).
>>>>>>>>>>>
>>>>>>>>>>> Robbie
>>>>>>>>>>>
>>>>>>>>>>> On 31 March 2016 at 18:02, Gibson, Jack
>>>>>>>>>>><ja...@paypal.com.invalid>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Hello -
>>>>>>>>>>>>
>>>>>>>>>>>> We are leveraging proton-j via the reactor framework and noticed a
>>>>>>>>>>>> discrepancy between proton-c and proton-j. With proton-c, we are
>>>>>>>>>>>>able
>>>>>>>>>>>> to establish 2-way authentication via SSL but with proton-j that is
>>>>>>>>>>>> unsuccessful. We opened a JIRA on this yesterday but figured we'd
>>>>>>>>>>>>ping
>>>>>>>>>>>> the lists as well.
>>>>>>>>>>>>
>>>>>>>>>>>> Below is the output from our test connecting to the dispatch router
>>>>>>>>>>>> configured for 2-way SSL auth.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 1.
>>>>>>>>>>>> 2. Client Error Message: from the log file
>>>>>>>>>>>> * AMQP framing error
>>>>>>>>>>>> * EventImpl{type=TRANSPORT_ERROR, context=TransportImpl
>>>>>>>>>>>>
>>>>>>>>>>>>[_connectionEndpoint=org.apache.qpid.proton.engine.impl.ConnectionIm
>>>>>>>>>>>>pl@6e
>>>>>>>>>>>> f351a0, org.apache.qpid.proton.engine.impl.TransportImpl@44c213d9]}
>>>>>>>>>>>> 3. Server Error Message: from the log file
>>>>>>>>>>>> *
>>>>>>>>>>>>
>>>>>>>>>>>> =64, totalFreeToHeap=0, transferBatchSize=64,
>>>>>>>>>>>> type=org.apache.qpid.dispatch.allocator, typeName=qd_timer_t,
>>>>>>>>>>>> typeSize=56)
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (info) Activating management agent
>>>>>>>>>>>>on
>>>>>>>>>>>> $management
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address
>>>>>>>>>>>>Registered:
>>>>>>>>>>>> $management
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address
>>>>>>>>>>>>Registered:
>>>>>>>>>>>> $management
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
>>>>>>>>>>>> FixedAddressEntity(bias=closest, fanout=single,
>>>>>>>>>>>>identity=fixedAddress/0,
>>>>>>>>>>>> name=fixedAddress/0, prefix=/,
>>>>>>>>>>>> type=org.apache.qpid.dispatch.fixedAddress)
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:00:47 2016 ROUTER (info) Configured Address: prefix=/
>>>>>>>>>>>> phase=0 fanout=QD_SCHEMA_FIXEDADDRESS_FANOUT_SINGLE
>>>>>>>>>>>> bias=QD_SCHEMA_FIXEDADDRESS_BIAS_CLOSEST
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
>>>>>>>>>>>> ListenerEntity(addr=0.0.0.0, authenticatePeer=True,
>>>>>>>>>>>> certDb=/home/vsharda/protected/pprootca_cert.pem,
>>>>>>>>>>>> certFile=/home/vsharda/protected/generic_cert.pem,
>>>>>>>>>>>> identity=listener/0.0.0.0:20009, idleTimeoutSeconds=16,
>>>>>>>>>>>> keyFile=/home/vsharda/protected/generic_key.pem,
>>>>>>>>>>>>maxFrameSize=65536,
>>>>>>>>>>>> name=listener/0.0.0.0:20009, password=pn2.GmdXmkKv.X7fPq.oYDFj8Cs,
>>>>>>>>>>>> port=20009, requireEncryption=True, requireSsl=True, role=normal,
>>>>>>>>>>>> saslMechanisms=EXTERNAL, stripAnnotations=both,
>>>>>>>>>>>> type=org.apache.qpid.dispatch.listener)
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:00:47 2016 CONN_MGR (info) Configured Listener:
>>>>>>>>>>>> 0.0.0.0:20009 proto=any role=normal
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:00:47 2016 SERVER (trace) Listening on 0.0.0.0:20009
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
>>>>>>>>>>>> ConsoleEntity(identity=console/0, name=console/0,
>>>>>>>>>>>> type=org.apache.qpid.dispatch.console, wsport=5673)
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:00:47 2016 SERVER (info) Operational, 4 Threads
>>>>>>>>>>>>Running
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (debug) Accepting incoming
>>>>>>>>>>>>connection
>>>>>>>>>>>> from 10.225.90.106:51196 to 0.0.0.0:20009
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) Configuring SSL on incoming
>>>>>>>>>>>> connection from 10.225.90.106:51196 to 0.0.0.0:20009
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Server SSL socket
>>>>>>>>>>>>created.
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:SSL/TLS connection
>>>>>>>>>>>>detected
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl( data
>>>>>>>>>>>> size=162 )
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Wrote 162 bytes to BIO
>>>>>>>>>>>> Layer, 0 left over
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Detected read-blocked
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl()
>>>>>>>>>>>> returning 162
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Read 3651 bytes from
>>>>>>>>>>>>BIO
>>>>>>>>>>>> Layer
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>>>>> returning 3651
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>>>>> returning 0
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>>>>> returning 0
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>>>>> returning 0
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>>>>> returning 0
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl( data
>>>>>>>>>>>> size=205 )
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Wrote 205 bytes to BIO
>>>>>>>>>>>> Layer, 0 left over
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:ERROR
>>>>>>>>>>>> amqp:connection:framing-error SSL Failure: error:140890C7:SSL
>>>>>>>>>>>> routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a
>>>>>>>>>>>>certificate
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]: <- EOS
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]: -> EOS
>>>>>>>>>>>>
>>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:SSL socket freed.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Jack
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>>>
>>>>>
Re: 2-WAY SSL Authentication in Proton-J and Dispatch Router
Posted by Robbie Gemmell <ro...@gmail.com>.
I posted a copy of broker and client side ssl trace logs (from using
-Djavax.net.debug=ssl) when running the code, plus a screenshot from
wireshark showing the client cert being sent. They are attached to the
JIRA, specifically:
https://issues.apache.org/jira/secure/attachment/12797708/ssl_logs1.tar.gz
I think it would be useful if you look at the ssl trace logging from
your attempts for any client side errors. Given the logging from
Dispatch seems to be indicating a problem where client didnt send a
certificate, I would probably expect to see something in there about
why it didn't/couldn't.
Robbie
On 7 April 2016 at 18:53, Powar, Suraj <sp...@paypal.com> wrote:
> Thanks for the response with the details. But the below information is not different than what you provided earlier and we updated our code as per your guidance and still got the same SSL certificate error.
>
>
> Note - all the SSL cert/keys are configured correctly, we tested the connectivity using OPENSSL and everything works as expected. The 1 way auth works as well, however the moment we enable 2 way auth with our Java client using reactor libraries we see SSL errors. Is it possible for you to share your SSL test logs with 2 way authentication working with your sample code?
>
>
>
> Regards,
> Suraj Powar
>
>
>
>
>
>
>
>
> On 4/7/16, 3:38 AM, "Robbie Gemmell" <ro...@gmail.com> wrote:
>
>>Hi Suraj,
>>
>>I previously attached the code I used to the JIRA Jack raised for this
>>(https://issues.apache.org/jira/browse/PROTON-1168) as mentioned in my
>>earlier reply. The file itself is at
>>https://issues.apache.org/jira/secure/attachment/12797022/PROTON-1168_reactor_ssl.patch.
>>As I said, I don't think the fact I was using 0.13.0-SNAPSHOT should
>>make any difference here.
>>
>>I used the test SSL resources from our JMS client build
>>(https://github.com/apache/qpid-jms/tree/master/qpid-jms-client/src/test/resources)
>>with the code, specifically the broker-jks.keystore +
>>broker-jks.truststore for the 6.0.2-SNAPSHOT Java broker I was using,
>>and then for the reactor client I used client.crt + ca.crt and a
>>client-private-key.pem file created by extracting the key from
>>client-pkcs12.keystore with openssl (I think by doing this: openssl
>>pkcs12 -nocerts -passin pass:password -in client-pkcs12.keystore
>>-passout pass:password -out client-private-key.pem). The files/keys
>>that use passwords all have it set as "password".
>>
>>Regarding your off-list follow-up to your mail, yes the list address
>>you used seems correct (ignoring the c&p error) but obviously the mail
>>did not arrive. What error did you actually get back?
>>
>>Robbie
>>
>>On 7 April 2016 at 00:41, Powar, Suraj <sp...@paypal.com> wrote:
>>> Hi All,
>>>
>>> So, we have tried to implement the proton-J 0.13.0 and still unable to successfully test the 2-way SSL with the reactor code.
>>>
>>> Attached is the screenshot of the server logs where you can see SSL error and below is the code snapshot where we are init SSL.
>>>
>>>
>>> //Code for SSL Initialization
>>> private void initSSL(Connection cnx) {
>>> SslDomain sslDomain = SslDomain.Factory.create();
>>> sslDomain.setCredentials(this.container.getCertificateFilePath(),
>>> this.container.getPrivateKeyFilePath(),
>>> this.container.getPassword());
>>> sslDomain.setTrustedCaDb(this.container.getCaCertFilePath());
>>> sslDomain.setPeerAuthentication(VerifyMode.VERIFY_PEER);
>>> sslDomain.init(Mode.CLIENT);
>>> cnx.getTransport().sasl().setMechanisms("EXTERNAL");
>>> System.out.println("SSL Domain is " + sslDomain.toString());
>>> cnx.getTransport().ssl(sslDomain);
>>>
>>> logger.debug("SSL initialization complete!");
>>> }
>>>
>>>
>>>
>>> Is there a possibility you could share a working sample reactor code using Proton-J 0.13.0?
>>>
>>>
>>> Regards,
>>> Suraj Powar
>>>
>>>
>>>
>>>
>>>
>>> On 4/5/16, 11:51 AM, "Gibson, Jack" <ja...@paypal.com> wrote:
>>>
>>>>+user list
>>>>
>>>>
>>>>CC'everyone else
>>>>
>>>>On 4/5/16, 12:05 PM, "Powar, Suraj" <sp...@paypal.com> wrote:
>>>>
>>>>>Hi,
>>>>>
>>>>>Yes we are using proton J reactor code. We updated the maven dependency
>>>>>to include the 0.13 version however we got the same result. It will
>>>>>helpful if you can share some sample code with proton J with 2 way SSL
>>>>>working. I will check the link again, our internal network may be
>>>>>blocking the link.
>>>>>
>>>>>
>>>>>Regards,
>>>>>Suraj
>>>>>
>>>>>Sent from my iPhone
>>>>>
>>>>>> On Apr 5, 2016, at 1:51 AM, Robbie Gemmell <ro...@gmail.com>
>>>>>>wrote:
>>>>>>
>>>>>> Hi Suraj
>>>>>>
>>>>>> The link is just a public pastebin, there aren't any restrictions on
>>>>>> it that I can alter. It works for me on a couple different
>>>>>> networks/devices, and the view count suggests it does for others too.
>>>>>> I have posted the contents as a patch on the JIRA in case you still
>>>>>> cant access it.
>>>>>>
>>>>>> I wasn't suggesting the 0.13.0-SNAPSHOT build would fix the issue you
>>>>>> are seeing (there aren't any related changes in it that I'm aware of),
>>>>>> just detailing what I used. As mentioned in my reply, it isn't clear
>>>>>> whether I even used the same component you have since the thread
>>>>>> mentioned the proton-j Reactor (which is what I used) however it turns
>>>>>> out the C code actually uses Messenger.
>>>>>>
>>>>>> If you keep discussion on the list (or JIRA) then other people can see
>>>>>> it too, and perhaps respond such as helping with the pastebin link
>>>>>> contents earlier.
>>>>>>
>>>>>> Robbie
>>>>>>
>>>>>>> On 4 April 2016 at 22:41, Powar, Suraj <sp...@paypal.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> So, we tried to run the 2 way SSL tests again using the 0.13 proton J
>>>>>>>library and still getting the same error.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Enclosed error image attachment
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Suraj Powar
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 4/4/16, 2:17 PM, "Powar, Suraj" <sp...@paypal.com> wrote:
>>>>>>>>
>>>>>>>> Hi Robbie,
>>>>>>>>
>>>>>>>> The link provided below - http://pastebin.com/TR5azYFR is not
>>>>>>>>accessible. Can you please provide access to this link so we can look
>>>>>>>>at the client code that you changed to established 2 way ssl?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Suraj Powar
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 4/4/16, 10:26 AM, "Gibson, Jack" <ja...@paypal.com> wrote:
>>>>>>>>>
>>>>>>>>> HmmmŠ shall discuss a bit more. Also, do we have the java/reactor
>>>>>>>>>code :)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On 4/4/16, 9:10 AM, "Robbie Gemmell" <ro...@gmail.com>
>>>>>>>>>>wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Jack,
>>>>>>>>>>
>>>>>>>>>> This isn't something I had tried before, but I was able to
>>>>>>>>>>establish a
>>>>>>>>>> connecting using the master/0.13.0-SNAPSHOT proton-j reactor and
>>>>>>>>>>send
>>>>>>>>>> messages to a 6.0.x/6.0.2-SNAPSHOT Qpid Java broker that was
>>>>>>>>>> configured to require SSL client certs and use the EXTERNAL SASL
>>>>>>>>>> mechanism (I didn't have a Dispatch set up appropriately and that
>>>>>>>>>>was
>>>>>>>>>> easier for me, plus the issue described seemed to be client-side).
>>>>>>>>>>
>>>>>>>>>> I had to make the following changes to the existing Send example to
>>>>>>>>>> add a required dependency, actually set where the sender is
>>>>>>>>>>attaching,
>>>>>>>>>> change the sasl mech, and configure use of ssl plus provide the
>>>>>>>>>> cert/trust details:
>>>>>>>>>>
>>>>>>>>>> http://pastebin.com/TR5azYFR
>>>>>>>>>>
>>>>>>>>>> I notice that the C code you attached to the JIRA (PROTON-1168 for
>>>>>>>>>> interested folks) is actually using Messenger with proton-c, and not
>>>>>>>>>> the Reactor as mentioned here for proton-j. I'm not sure if your
>>>>>>>>>>Java
>>>>>>>>>> code is actually doing the same since you didn't include it, but
>>>>>>>>>>that
>>>>>>>>>> isn't something I have tried either in any case. I do seem to recall
>>>>>>>>>> previous discussion around proton-c Messenger that it isn't actually
>>>>>>>>>> possible to set the particular sasl mechanism with Messenger (though
>>>>>>>>>> that would presumably be a separate issue from the one the Dispatch
>>>>>>>>>> logs suggest occurred, of not sending a cert as requested/required).
>>>>>>>>>>
>>>>>>>>>> Robbie
>>>>>>>>>>
>>>>>>>>>> On 31 March 2016 at 18:02, Gibson, Jack
>>>>>>>>>><ja...@paypal.com.invalid>
>>>>>>>>>> wrote:
>>>>>>>>>>> Hello -
>>>>>>>>>>>
>>>>>>>>>>> We are leveraging proton-j via the reactor framework and noticed a
>>>>>>>>>>> discrepancy between proton-c and proton-j. With proton-c, we are
>>>>>>>>>>>able
>>>>>>>>>>> to establish 2-way authentication via SSL but with proton-j that is
>>>>>>>>>>> unsuccessful. We opened a JIRA on this yesterday but figured we'd
>>>>>>>>>>>ping
>>>>>>>>>>> the lists as well.
>>>>>>>>>>>
>>>>>>>>>>> Below is the output from our test connecting to the dispatch router
>>>>>>>>>>> configured for 2-way SSL auth.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 1.
>>>>>>>>>>> 2. Client Error Message: from the log file
>>>>>>>>>>> * AMQP framing error
>>>>>>>>>>> * EventImpl{type=TRANSPORT_ERROR, context=TransportImpl
>>>>>>>>>>>
>>>>>>>>>>>[_connectionEndpoint=org.apache.qpid.proton.engine.impl.ConnectionIm
>>>>>>>>>>>pl@6e
>>>>>>>>>>> f351a0, org.apache.qpid.proton.engine.impl.TransportImpl@44c213d9]}
>>>>>>>>>>> 3. Server Error Message: from the log file
>>>>>>>>>>> *
>>>>>>>>>>>
>>>>>>>>>>> =64, totalFreeToHeap=0, transferBatchSize=64,
>>>>>>>>>>> type=org.apache.qpid.dispatch.allocator, typeName=qd_timer_t,
>>>>>>>>>>> typeSize=56)
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (info) Activating management agent
>>>>>>>>>>>on
>>>>>>>>>>> $management
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address
>>>>>>>>>>>Registered:
>>>>>>>>>>> $management
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address
>>>>>>>>>>>Registered:
>>>>>>>>>>> $management
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
>>>>>>>>>>> FixedAddressEntity(bias=closest, fanout=single,
>>>>>>>>>>>identity=fixedAddress/0,
>>>>>>>>>>> name=fixedAddress/0, prefix=/,
>>>>>>>>>>> type=org.apache.qpid.dispatch.fixedAddress)
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:00:47 2016 ROUTER (info) Configured Address: prefix=/
>>>>>>>>>>> phase=0 fanout=QD_SCHEMA_FIXEDADDRESS_FANOUT_SINGLE
>>>>>>>>>>> bias=QD_SCHEMA_FIXEDADDRESS_BIAS_CLOSEST
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
>>>>>>>>>>> ListenerEntity(addr=0.0.0.0, authenticatePeer=True,
>>>>>>>>>>> certDb=/home/vsharda/protected/pprootca_cert.pem,
>>>>>>>>>>> certFile=/home/vsharda/protected/generic_cert.pem,
>>>>>>>>>>> identity=listener/0.0.0.0:20009, idleTimeoutSeconds=16,
>>>>>>>>>>> keyFile=/home/vsharda/protected/generic_key.pem,
>>>>>>>>>>>maxFrameSize=65536,
>>>>>>>>>>> name=listener/0.0.0.0:20009, password=pn2.GmdXmkKv.X7fPq.oYDFj8Cs,
>>>>>>>>>>> port=20009, requireEncryption=True, requireSsl=True, role=normal,
>>>>>>>>>>> saslMechanisms=EXTERNAL, stripAnnotations=both,
>>>>>>>>>>> type=org.apache.qpid.dispatch.listener)
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:00:47 2016 CONN_MGR (info) Configured Listener:
>>>>>>>>>>> 0.0.0.0:20009 proto=any role=normal
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:00:47 2016 SERVER (trace) Listening on 0.0.0.0:20009
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
>>>>>>>>>>> ConsoleEntity(identity=console/0, name=console/0,
>>>>>>>>>>> type=org.apache.qpid.dispatch.console, wsport=5673)
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:00:47 2016 SERVER (info) Operational, 4 Threads
>>>>>>>>>>>Running
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (debug) Accepting incoming
>>>>>>>>>>>connection
>>>>>>>>>>> from 10.225.90.106:51196 to 0.0.0.0:20009
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) Configuring SSL on incoming
>>>>>>>>>>> connection from 10.225.90.106:51196 to 0.0.0.0:20009
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Server SSL socket
>>>>>>>>>>>created.
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:SSL/TLS connection
>>>>>>>>>>>detected
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl( data
>>>>>>>>>>> size=162 )
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Wrote 162 bytes to BIO
>>>>>>>>>>> Layer, 0 left over
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Detected read-blocked
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl()
>>>>>>>>>>> returning 162
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Read 3651 bytes from
>>>>>>>>>>>BIO
>>>>>>>>>>> Layer
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>>>> returning 3651
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>>>> returning 0
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>>>> returning 0
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>>>> returning 0
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>>>> returning 0
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl( data
>>>>>>>>>>> size=205 )
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Wrote 205 bytes to BIO
>>>>>>>>>>> Layer, 0 left over
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:ERROR
>>>>>>>>>>> amqp:connection:framing-error SSL Failure: error:140890C7:SSL
>>>>>>>>>>> routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a
>>>>>>>>>>>certificate
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]: <- EOS
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]: -> EOS
>>>>>>>>>>>
>>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:SSL socket freed.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Jack
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>>
>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: 2-WAY SSL Authentication in Proton-J and Dispatch Router
Posted by "Powar, Suraj" <sp...@paypal.com.INVALID>.
Thanks for the response with the details. But the below information is not different than what you provided earlier and we updated our code as per your guidance and still got the same SSL certificate error.
Note - all the SSL cert/keys are configured correctly, we tested the connectivity using OPENSSL and everything works as expected. The 1 way auth works as well, however the moment we enable 2 way auth with our Java client using reactor libraries we see SSL errors. Is it possible for you to share your SSL test logs with 2 way authentication working with your sample code?
Regards,
Suraj Powar
On 4/7/16, 3:38 AM, "Robbie Gemmell" <ro...@gmail.com> wrote:
>Hi Suraj,
>
>I previously attached the code I used to the JIRA Jack raised for this
>(https://issues.apache.org/jira/browse/PROTON-1168) as mentioned in my
>earlier reply. The file itself is at
>https://issues.apache.org/jira/secure/attachment/12797022/PROTON-1168_reactor_ssl.patch.
>As I said, I don't think the fact I was using 0.13.0-SNAPSHOT should
>make any difference here.
>
>I used the test SSL resources from our JMS client build
>(https://github.com/apache/qpid-jms/tree/master/qpid-jms-client/src/test/resources)
>with the code, specifically the broker-jks.keystore +
>broker-jks.truststore for the 6.0.2-SNAPSHOT Java broker I was using,
>and then for the reactor client I used client.crt + ca.crt and a
>client-private-key.pem file created by extracting the key from
>client-pkcs12.keystore with openssl (I think by doing this: openssl
>pkcs12 -nocerts -passin pass:password -in client-pkcs12.keystore
>-passout pass:password -out client-private-key.pem). The files/keys
>that use passwords all have it set as "password".
>
>Regarding your off-list follow-up to your mail, yes the list address
>you used seems correct (ignoring the c&p error) but obviously the mail
>did not arrive. What error did you actually get back?
>
>Robbie
>
>On 7 April 2016 at 00:41, Powar, Suraj <sp...@paypal.com> wrote:
>> Hi All,
>>
>> So, we have tried to implement the proton-J 0.13.0 and still unable to successfully test the 2-way SSL with the reactor code.
>>
>> Attached is the screenshot of the server logs where you can see SSL error and below is the code snapshot where we are init SSL.
>>
>>
>> //Code for SSL Initialization
>> private void initSSL(Connection cnx) {
>> SslDomain sslDomain = SslDomain.Factory.create();
>> sslDomain.setCredentials(this.container.getCertificateFilePath(),
>> this.container.getPrivateKeyFilePath(),
>> this.container.getPassword());
>> sslDomain.setTrustedCaDb(this.container.getCaCertFilePath());
>> sslDomain.setPeerAuthentication(VerifyMode.VERIFY_PEER);
>> sslDomain.init(Mode.CLIENT);
>> cnx.getTransport().sasl().setMechanisms("EXTERNAL");
>> System.out.println("SSL Domain is " + sslDomain.toString());
>> cnx.getTransport().ssl(sslDomain);
>>
>> logger.debug("SSL initialization complete!");
>> }
>>
>>
>>
>> Is there a possibility you could share a working sample reactor code using Proton-J 0.13.0?
>>
>>
>> Regards,
>> Suraj Powar
>>
>>
>>
>>
>>
>> On 4/5/16, 11:51 AM, "Gibson, Jack" <ja...@paypal.com> wrote:
>>
>>>+user list
>>>
>>>
>>>CC'everyone else
>>>
>>>On 4/5/16, 12:05 PM, "Powar, Suraj" <sp...@paypal.com> wrote:
>>>
>>>>Hi,
>>>>
>>>>Yes we are using proton J reactor code. We updated the maven dependency
>>>>to include the 0.13 version however we got the same result. It will
>>>>helpful if you can share some sample code with proton J with 2 way SSL
>>>>working. I will check the link again, our internal network may be
>>>>blocking the link.
>>>>
>>>>
>>>>Regards,
>>>>Suraj
>>>>
>>>>Sent from my iPhone
>>>>
>>>>> On Apr 5, 2016, at 1:51 AM, Robbie Gemmell <ro...@gmail.com>
>>>>>wrote:
>>>>>
>>>>> Hi Suraj
>>>>>
>>>>> The link is just a public pastebin, there aren't any restrictions on
>>>>> it that I can alter. It works for me on a couple different
>>>>> networks/devices, and the view count suggests it does for others too.
>>>>> I have posted the contents as a patch on the JIRA in case you still
>>>>> cant access it.
>>>>>
>>>>> I wasn't suggesting the 0.13.0-SNAPSHOT build would fix the issue you
>>>>> are seeing (there aren't any related changes in it that I'm aware of),
>>>>> just detailing what I used. As mentioned in my reply, it isn't clear
>>>>> whether I even used the same component you have since the thread
>>>>> mentioned the proton-j Reactor (which is what I used) however it turns
>>>>> out the C code actually uses Messenger.
>>>>>
>>>>> If you keep discussion on the list (or JIRA) then other people can see
>>>>> it too, and perhaps respond such as helping with the pastebin link
>>>>> contents earlier.
>>>>>
>>>>> Robbie
>>>>>
>>>>>> On 4 April 2016 at 22:41, Powar, Suraj <sp...@paypal.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> So, we tried to run the 2 way SSL tests again using the 0.13 proton J
>>>>>>library and still getting the same error.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Enclosed error image attachment
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Suraj Powar
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 4/4/16, 2:17 PM, "Powar, Suraj" <sp...@paypal.com> wrote:
>>>>>>>
>>>>>>> Hi Robbie,
>>>>>>>
>>>>>>> The link provided below - http://pastebin.com/TR5azYFR is not
>>>>>>>accessible. Can you please provide access to this link so we can look
>>>>>>>at the client code that you changed to established 2 way ssl?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>> Suraj Powar
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 4/4/16, 10:26 AM, "Gibson, Jack" <ja...@paypal.com> wrote:
>>>>>>>>
>>>>>>>> HmmmŠ shall discuss a bit more. Also, do we have the java/reactor
>>>>>>>>code :)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 4/4/16, 9:10 AM, "Robbie Gemmell" <ro...@gmail.com>
>>>>>>>>>wrote:
>>>>>>>>>
>>>>>>>>> Hi Jack,
>>>>>>>>>
>>>>>>>>> This isn't something I had tried before, but I was able to
>>>>>>>>>establish a
>>>>>>>>> connecting using the master/0.13.0-SNAPSHOT proton-j reactor and
>>>>>>>>>send
>>>>>>>>> messages to a 6.0.x/6.0.2-SNAPSHOT Qpid Java broker that was
>>>>>>>>> configured to require SSL client certs and use the EXTERNAL SASL
>>>>>>>>> mechanism (I didn't have a Dispatch set up appropriately and that
>>>>>>>>>was
>>>>>>>>> easier for me, plus the issue described seemed to be client-side).
>>>>>>>>>
>>>>>>>>> I had to make the following changes to the existing Send example to
>>>>>>>>> add a required dependency, actually set where the sender is
>>>>>>>>>attaching,
>>>>>>>>> change the sasl mech, and configure use of ssl plus provide the
>>>>>>>>> cert/trust details:
>>>>>>>>>
>>>>>>>>> http://pastebin.com/TR5azYFR
>>>>>>>>>
>>>>>>>>> I notice that the C code you attached to the JIRA (PROTON-1168 for
>>>>>>>>> interested folks) is actually using Messenger with proton-c, and not
>>>>>>>>> the Reactor as mentioned here for proton-j. I'm not sure if your
>>>>>>>>>Java
>>>>>>>>> code is actually doing the same since you didn't include it, but
>>>>>>>>>that
>>>>>>>>> isn't something I have tried either in any case. I do seem to recall
>>>>>>>>> previous discussion around proton-c Messenger that it isn't actually
>>>>>>>>> possible to set the particular sasl mechanism with Messenger (though
>>>>>>>>> that would presumably be a separate issue from the one the Dispatch
>>>>>>>>> logs suggest occurred, of not sending a cert as requested/required).
>>>>>>>>>
>>>>>>>>> Robbie
>>>>>>>>>
>>>>>>>>> On 31 March 2016 at 18:02, Gibson, Jack
>>>>>>>>><ja...@paypal.com.invalid>
>>>>>>>>> wrote:
>>>>>>>>>> Hello -
>>>>>>>>>>
>>>>>>>>>> We are leveraging proton-j via the reactor framework and noticed a
>>>>>>>>>> discrepancy between proton-c and proton-j. With proton-c, we are
>>>>>>>>>>able
>>>>>>>>>> to establish 2-way authentication via SSL but with proton-j that is
>>>>>>>>>> unsuccessful. We opened a JIRA on this yesterday but figured we'd
>>>>>>>>>>ping
>>>>>>>>>> the lists as well.
>>>>>>>>>>
>>>>>>>>>> Below is the output from our test connecting to the dispatch router
>>>>>>>>>> configured for 2-way SSL auth.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 1.
>>>>>>>>>> 2. Client Error Message: from the log file
>>>>>>>>>> * AMQP framing error
>>>>>>>>>> * EventImpl{type=TRANSPORT_ERROR, context=TransportImpl
>>>>>>>>>>
>>>>>>>>>>[_connectionEndpoint=org.apache.qpid.proton.engine.impl.ConnectionIm
>>>>>>>>>>pl@6e
>>>>>>>>>> f351a0, org.apache.qpid.proton.engine.impl.TransportImpl@44c213d9]}
>>>>>>>>>> 3. Server Error Message: from the log file
>>>>>>>>>> *
>>>>>>>>>>
>>>>>>>>>> =64, totalFreeToHeap=0, transferBatchSize=64,
>>>>>>>>>> type=org.apache.qpid.dispatch.allocator, typeName=qd_timer_t,
>>>>>>>>>> typeSize=56)
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (info) Activating management agent
>>>>>>>>>>on
>>>>>>>>>> $management
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address
>>>>>>>>>>Registered:
>>>>>>>>>> $management
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address
>>>>>>>>>>Registered:
>>>>>>>>>> $management
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
>>>>>>>>>> FixedAddressEntity(bias=closest, fanout=single,
>>>>>>>>>>identity=fixedAddress/0,
>>>>>>>>>> name=fixedAddress/0, prefix=/,
>>>>>>>>>> type=org.apache.qpid.dispatch.fixedAddress)
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:00:47 2016 ROUTER (info) Configured Address: prefix=/
>>>>>>>>>> phase=0 fanout=QD_SCHEMA_FIXEDADDRESS_FANOUT_SINGLE
>>>>>>>>>> bias=QD_SCHEMA_FIXEDADDRESS_BIAS_CLOSEST
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
>>>>>>>>>> ListenerEntity(addr=0.0.0.0, authenticatePeer=True,
>>>>>>>>>> certDb=/home/vsharda/protected/pprootca_cert.pem,
>>>>>>>>>> certFile=/home/vsharda/protected/generic_cert.pem,
>>>>>>>>>> identity=listener/0.0.0.0:20009, idleTimeoutSeconds=16,
>>>>>>>>>> keyFile=/home/vsharda/protected/generic_key.pem,
>>>>>>>>>>maxFrameSize=65536,
>>>>>>>>>> name=listener/0.0.0.0:20009, password=pn2.GmdXmkKv.X7fPq.oYDFj8Cs,
>>>>>>>>>> port=20009, requireEncryption=True, requireSsl=True, role=normal,
>>>>>>>>>> saslMechanisms=EXTERNAL, stripAnnotations=both,
>>>>>>>>>> type=org.apache.qpid.dispatch.listener)
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:00:47 2016 CONN_MGR (info) Configured Listener:
>>>>>>>>>> 0.0.0.0:20009 proto=any role=normal
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:00:47 2016 SERVER (trace) Listening on 0.0.0.0:20009
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
>>>>>>>>>> ConsoleEntity(identity=console/0, name=console/0,
>>>>>>>>>> type=org.apache.qpid.dispatch.console, wsport=5673)
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:00:47 2016 SERVER (info) Operational, 4 Threads
>>>>>>>>>>Running
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (debug) Accepting incoming
>>>>>>>>>>connection
>>>>>>>>>> from 10.225.90.106:51196 to 0.0.0.0:20009
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) Configuring SSL on incoming
>>>>>>>>>> connection from 10.225.90.106:51196 to 0.0.0.0:20009
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Server SSL socket
>>>>>>>>>>created.
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:SSL/TLS connection
>>>>>>>>>>detected
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl( data
>>>>>>>>>> size=162 )
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Wrote 162 bytes to BIO
>>>>>>>>>> Layer, 0 left over
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Detected read-blocked
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl()
>>>>>>>>>> returning 162
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Read 3651 bytes from
>>>>>>>>>>BIO
>>>>>>>>>> Layer
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>>> returning 3651
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>>> returning 0
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>>> returning 0
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>>> returning 0
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>>> returning 0
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl( data
>>>>>>>>>> size=205 )
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Wrote 205 bytes to BIO
>>>>>>>>>> Layer, 0 left over
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:ERROR
>>>>>>>>>> amqp:connection:framing-error SSL Failure: error:140890C7:SSL
>>>>>>>>>> routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a
>>>>>>>>>>certificate
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]: <- EOS
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]: -> EOS
>>>>>>>>>>
>>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:SSL socket freed.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Jack
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>>
>>>
Re: 2-WAY SSL Authentication in Proton-J and Dispatch Router
Posted by Robbie Gemmell <ro...@gmail.com>.
Hi Suraj,
I previously attached the code I used to the JIRA Jack raised for this
(https://issues.apache.org/jira/browse/PROTON-1168) as mentioned in my
earlier reply. The file itself is at
https://issues.apache.org/jira/secure/attachment/12797022/PROTON-1168_reactor_ssl.patch.
As I said, I don't think the fact I was using 0.13.0-SNAPSHOT should
make any difference here.
I used the test SSL resources from our JMS client build
(https://github.com/apache/qpid-jms/tree/master/qpid-jms-client/src/test/resources)
with the code, specifically the broker-jks.keystore +
broker-jks.truststore for the 6.0.2-SNAPSHOT Java broker I was using,
and then for the reactor client I used client.crt + ca.crt and a
client-private-key.pem file created by extracting the key from
client-pkcs12.keystore with openssl (I think by doing this: openssl
pkcs12 -nocerts -passin pass:password -in client-pkcs12.keystore
-passout pass:password -out client-private-key.pem). The files/keys
that use passwords all have it set as "password".
Regarding your off-list follow-up to your mail, yes the list address
you used seems correct (ignoring the c&p error) but obviously the mail
did not arrive. What error did you actually get back?
Robbie
On 7 April 2016 at 00:41, Powar, Suraj <sp...@paypal.com> wrote:
> Hi All,
>
> So, we have tried to implement the proton-J 0.13.0 and still unable to successfully test the 2-way SSL with the reactor code.
>
> Attached is the screenshot of the server logs where you can see SSL error and below is the code snapshot where we are init SSL.
>
>
> //Code for SSL Initialization
> private void initSSL(Connection cnx) {
> SslDomain sslDomain = SslDomain.Factory.create();
> sslDomain.setCredentials(this.container.getCertificateFilePath(),
> this.container.getPrivateKeyFilePath(),
> this.container.getPassword());
> sslDomain.setTrustedCaDb(this.container.getCaCertFilePath());
> sslDomain.setPeerAuthentication(VerifyMode.VERIFY_PEER);
> sslDomain.init(Mode.CLIENT);
> cnx.getTransport().sasl().setMechanisms("EXTERNAL");
> System.out.println("SSL Domain is " + sslDomain.toString());
> cnx.getTransport().ssl(sslDomain);
>
> logger.debug("SSL initialization complete!");
> }
>
>
>
> Is there a possibility you could share a working sample reactor code using Proton-J 0.13.0?
>
>
> Regards,
> Suraj Powar
>
>
>
>
>
> On 4/5/16, 11:51 AM, "Gibson, Jack" <ja...@paypal.com> wrote:
>
>>+user list
>>
>>
>>CC'everyone else
>>
>>On 4/5/16, 12:05 PM, "Powar, Suraj" <sp...@paypal.com> wrote:
>>
>>>Hi,
>>>
>>>Yes we are using proton J reactor code. We updated the maven dependency
>>>to include the 0.13 version however we got the same result. It will
>>>helpful if you can share some sample code with proton J with 2 way SSL
>>>working. I will check the link again, our internal network may be
>>>blocking the link.
>>>
>>>
>>>Regards,
>>>Suraj
>>>
>>>Sent from my iPhone
>>>
>>>> On Apr 5, 2016, at 1:51 AM, Robbie Gemmell <ro...@gmail.com>
>>>>wrote:
>>>>
>>>> Hi Suraj
>>>>
>>>> The link is just a public pastebin, there aren't any restrictions on
>>>> it that I can alter. It works for me on a couple different
>>>> networks/devices, and the view count suggests it does for others too.
>>>> I have posted the contents as a patch on the JIRA in case you still
>>>> cant access it.
>>>>
>>>> I wasn't suggesting the 0.13.0-SNAPSHOT build would fix the issue you
>>>> are seeing (there aren't any related changes in it that I'm aware of),
>>>> just detailing what I used. As mentioned in my reply, it isn't clear
>>>> whether I even used the same component you have since the thread
>>>> mentioned the proton-j Reactor (which is what I used) however it turns
>>>> out the C code actually uses Messenger.
>>>>
>>>> If you keep discussion on the list (or JIRA) then other people can see
>>>> it too, and perhaps respond such as helping with the pastebin link
>>>> contents earlier.
>>>>
>>>> Robbie
>>>>
>>>>> On 4 April 2016 at 22:41, Powar, Suraj <sp...@paypal.com> wrote:
>>>>> Hi,
>>>>>
>>>>> So, we tried to run the 2 way SSL tests again using the 0.13 proton J
>>>>>library and still getting the same error.
>>>>>
>>>>>
>>>>>
>>>>> Enclosed error image attachment
>>>>>
>>>>>
>>>>> Regards,
>>>>> Suraj Powar
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On 4/4/16, 2:17 PM, "Powar, Suraj" <sp...@paypal.com> wrote:
>>>>>>
>>>>>> Hi Robbie,
>>>>>>
>>>>>> The link provided below - http://pastebin.com/TR5azYFR is not
>>>>>>accessible. Can you please provide access to this link so we can look
>>>>>>at the client code that you changed to established 2 way ssl?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Suraj Powar
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 4/4/16, 10:26 AM, "Gibson, Jack" <ja...@paypal.com> wrote:
>>>>>>>
>>>>>>> HmmmŠ shall discuss a bit more. Also, do we have the java/reactor
>>>>>>>code :)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 4/4/16, 9:10 AM, "Robbie Gemmell" <ro...@gmail.com>
>>>>>>>>wrote:
>>>>>>>>
>>>>>>>> Hi Jack,
>>>>>>>>
>>>>>>>> This isn't something I had tried before, but I was able to
>>>>>>>>establish a
>>>>>>>> connecting using the master/0.13.0-SNAPSHOT proton-j reactor and
>>>>>>>>send
>>>>>>>> messages to a 6.0.x/6.0.2-SNAPSHOT Qpid Java broker that was
>>>>>>>> configured to require SSL client certs and use the EXTERNAL SASL
>>>>>>>> mechanism (I didn't have a Dispatch set up appropriately and that
>>>>>>>>was
>>>>>>>> easier for me, plus the issue described seemed to be client-side).
>>>>>>>>
>>>>>>>> I had to make the following changes to the existing Send example to
>>>>>>>> add a required dependency, actually set where the sender is
>>>>>>>>attaching,
>>>>>>>> change the sasl mech, and configure use of ssl plus provide the
>>>>>>>> cert/trust details:
>>>>>>>>
>>>>>>>> http://pastebin.com/TR5azYFR
>>>>>>>>
>>>>>>>> I notice that the C code you attached to the JIRA (PROTON-1168 for
>>>>>>>> interested folks) is actually using Messenger with proton-c, and not
>>>>>>>> the Reactor as mentioned here for proton-j. I'm not sure if your
>>>>>>>>Java
>>>>>>>> code is actually doing the same since you didn't include it, but
>>>>>>>>that
>>>>>>>> isn't something I have tried either in any case. I do seem to recall
>>>>>>>> previous discussion around proton-c Messenger that it isn't actually
>>>>>>>> possible to set the particular sasl mechanism with Messenger (though
>>>>>>>> that would presumably be a separate issue from the one the Dispatch
>>>>>>>> logs suggest occurred, of not sending a cert as requested/required).
>>>>>>>>
>>>>>>>> Robbie
>>>>>>>>
>>>>>>>> On 31 March 2016 at 18:02, Gibson, Jack
>>>>>>>><ja...@paypal.com.invalid>
>>>>>>>> wrote:
>>>>>>>>> Hello -
>>>>>>>>>
>>>>>>>>> We are leveraging proton-j via the reactor framework and noticed a
>>>>>>>>> discrepancy between proton-c and proton-j. With proton-c, we are
>>>>>>>>>able
>>>>>>>>> to establish 2-way authentication via SSL but with proton-j that is
>>>>>>>>> unsuccessful. We opened a JIRA on this yesterday but figured we'd
>>>>>>>>>ping
>>>>>>>>> the lists as well.
>>>>>>>>>
>>>>>>>>> Below is the output from our test connecting to the dispatch router
>>>>>>>>> configured for 2-way SSL auth.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1.
>>>>>>>>> 2. Client Error Message: from the log file
>>>>>>>>> * AMQP framing error
>>>>>>>>> * EventImpl{type=TRANSPORT_ERROR, context=TransportImpl
>>>>>>>>>
>>>>>>>>>[_connectionEndpoint=org.apache.qpid.proton.engine.impl.ConnectionIm
>>>>>>>>>pl@6e
>>>>>>>>> f351a0, org.apache.qpid.proton.engine.impl.TransportImpl@44c213d9]}
>>>>>>>>> 3. Server Error Message: from the log file
>>>>>>>>> *
>>>>>>>>>
>>>>>>>>> =64, totalFreeToHeap=0, transferBatchSize=64,
>>>>>>>>> type=org.apache.qpid.dispatch.allocator, typeName=qd_timer_t,
>>>>>>>>> typeSize=56)
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (info) Activating management agent
>>>>>>>>>on
>>>>>>>>> $management
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address
>>>>>>>>>Registered:
>>>>>>>>> $management
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address
>>>>>>>>>Registered:
>>>>>>>>> $management
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
>>>>>>>>> FixedAddressEntity(bias=closest, fanout=single,
>>>>>>>>>identity=fixedAddress/0,
>>>>>>>>> name=fixedAddress/0, prefix=/,
>>>>>>>>> type=org.apache.qpid.dispatch.fixedAddress)
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:00:47 2016 ROUTER (info) Configured Address: prefix=/
>>>>>>>>> phase=0 fanout=QD_SCHEMA_FIXEDADDRESS_FANOUT_SINGLE
>>>>>>>>> bias=QD_SCHEMA_FIXEDADDRESS_BIAS_CLOSEST
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
>>>>>>>>> ListenerEntity(addr=0.0.0.0, authenticatePeer=True,
>>>>>>>>> certDb=/home/vsharda/protected/pprootca_cert.pem,
>>>>>>>>> certFile=/home/vsharda/protected/generic_cert.pem,
>>>>>>>>> identity=listener/0.0.0.0:20009, idleTimeoutSeconds=16,
>>>>>>>>> keyFile=/home/vsharda/protected/generic_key.pem,
>>>>>>>>>maxFrameSize=65536,
>>>>>>>>> name=listener/0.0.0.0:20009, password=pn2.GmdXmkKv.X7fPq.oYDFj8Cs,
>>>>>>>>> port=20009, requireEncryption=True, requireSsl=True, role=normal,
>>>>>>>>> saslMechanisms=EXTERNAL, stripAnnotations=both,
>>>>>>>>> type=org.apache.qpid.dispatch.listener)
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:00:47 2016 CONN_MGR (info) Configured Listener:
>>>>>>>>> 0.0.0.0:20009 proto=any role=normal
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:00:47 2016 SERVER (trace) Listening on 0.0.0.0:20009
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
>>>>>>>>> ConsoleEntity(identity=console/0, name=console/0,
>>>>>>>>> type=org.apache.qpid.dispatch.console, wsport=5673)
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:00:47 2016 SERVER (info) Operational, 4 Threads
>>>>>>>>>Running
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (debug) Accepting incoming
>>>>>>>>>connection
>>>>>>>>> from 10.225.90.106:51196 to 0.0.0.0:20009
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) Configuring SSL on incoming
>>>>>>>>> connection from 10.225.90.106:51196 to 0.0.0.0:20009
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Server SSL socket
>>>>>>>>>created.
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:SSL/TLS connection
>>>>>>>>>detected
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl( data
>>>>>>>>> size=162 )
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Wrote 162 bytes to BIO
>>>>>>>>> Layer, 0 left over
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Detected read-blocked
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl()
>>>>>>>>> returning 162
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Read 3651 bytes from
>>>>>>>>>BIO
>>>>>>>>> Layer
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>> returning 3651
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>> returning 0
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>> returning 0
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>> returning 0
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>>>> returning 0
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl( data
>>>>>>>>> size=205 )
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Wrote 205 bytes to BIO
>>>>>>>>> Layer, 0 left over
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:ERROR
>>>>>>>>> amqp:connection:framing-error SSL Failure: error:140890C7:SSL
>>>>>>>>> routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a
>>>>>>>>>certificate
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]: <- EOS
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]: -> EOS
>>>>>>>>>
>>>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:SSL socket freed.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Jack
>>>>>>>>
>>>>>>>>
>>>>>>>>---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: 2-WAY SSL Authentication in Proton-J and Dispatch Router
Posted by "Gibson, Jack" <ja...@paypal.com.INVALID>.
+user list
CC'everyone else
On 4/5/16, 12:05 PM, "Powar, Suraj" <sp...@paypal.com> wrote:
>Hi,
>
>Yes we are using proton J reactor code. We updated the maven dependency
>to include the 0.13 version however we got the same result. It will
>helpful if you can share some sample code with proton J with 2 way SSL
>working. I will check the link again, our internal network may be
>blocking the link.
>
>
>Regards,
>Suraj
>
>Sent from my iPhone
>
>> On Apr 5, 2016, at 1:51 AM, Robbie Gemmell <ro...@gmail.com>
>>wrote:
>>
>> Hi Suraj
>>
>> The link is just a public pastebin, there aren't any restrictions on
>> it that I can alter. It works for me on a couple different
>> networks/devices, and the view count suggests it does for others too.
>> I have posted the contents as a patch on the JIRA in case you still
>> cant access it.
>>
>> I wasn't suggesting the 0.13.0-SNAPSHOT build would fix the issue you
>> are seeing (there aren't any related changes in it that I'm aware of),
>> just detailing what I used. As mentioned in my reply, it isn't clear
>> whether I even used the same component you have since the thread
>> mentioned the proton-j Reactor (which is what I used) however it turns
>> out the C code actually uses Messenger.
>>
>> If you keep discussion on the list (or JIRA) then other people can see
>> it too, and perhaps respond such as helping with the pastebin link
>> contents earlier.
>>
>> Robbie
>>
>>> On 4 April 2016 at 22:41, Powar, Suraj <sp...@paypal.com> wrote:
>>> Hi,
>>>
>>> So, we tried to run the 2 way SSL tests again using the 0.13 proton J
>>>library and still getting the same error.
>>>
>>>
>>>
>>> Enclosed error image attachment
>>>
>>>
>>> Regards,
>>> Suraj Powar
>>>
>>>
>>>
>>>
>>>> On 4/4/16, 2:17 PM, "Powar, Suraj" <sp...@paypal.com> wrote:
>>>>
>>>> Hi Robbie,
>>>>
>>>> The link provided below - http://pastebin.com/TR5azYFR is not
>>>>accessible. Can you please provide access to this link so we can look
>>>>at the client code that you changed to established 2 way ssl?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Regards,
>>>> Suraj Powar
>>>>
>>>>
>>>>
>>>>
>>>>> On 4/4/16, 10:26 AM, "Gibson, Jack" <ja...@paypal.com> wrote:
>>>>>
>>>>> HmmmŠ shall discuss a bit more. Also, do we have the java/reactor
>>>>>code :)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On 4/4/16, 9:10 AM, "Robbie Gemmell" <ro...@gmail.com>
>>>>>>wrote:
>>>>>>
>>>>>> Hi Jack,
>>>>>>
>>>>>> This isn't something I had tried before, but I was able to
>>>>>>establish a
>>>>>> connecting using the master/0.13.0-SNAPSHOT proton-j reactor and
>>>>>>send
>>>>>> messages to a 6.0.x/6.0.2-SNAPSHOT Qpid Java broker that was
>>>>>> configured to require SSL client certs and use the EXTERNAL SASL
>>>>>> mechanism (I didn't have a Dispatch set up appropriately and that
>>>>>>was
>>>>>> easier for me, plus the issue described seemed to be client-side).
>>>>>>
>>>>>> I had to make the following changes to the existing Send example to
>>>>>> add a required dependency, actually set where the sender is
>>>>>>attaching,
>>>>>> change the sasl mech, and configure use of ssl plus provide the
>>>>>> cert/trust details:
>>>>>>
>>>>>> http://pastebin.com/TR5azYFR
>>>>>>
>>>>>> I notice that the C code you attached to the JIRA (PROTON-1168 for
>>>>>> interested folks) is actually using Messenger with proton-c, and not
>>>>>> the Reactor as mentioned here for proton-j. I'm not sure if your
>>>>>>Java
>>>>>> code is actually doing the same since you didn't include it, but
>>>>>>that
>>>>>> isn't something I have tried either in any case. I do seem to recall
>>>>>> previous discussion around proton-c Messenger that it isn't actually
>>>>>> possible to set the particular sasl mechanism with Messenger (though
>>>>>> that would presumably be a separate issue from the one the Dispatch
>>>>>> logs suggest occurred, of not sending a cert as requested/required).
>>>>>>
>>>>>> Robbie
>>>>>>
>>>>>> On 31 March 2016 at 18:02, Gibson, Jack
>>>>>><ja...@paypal.com.invalid>
>>>>>> wrote:
>>>>>>> Hello -
>>>>>>>
>>>>>>> We are leveraging proton-j via the reactor framework and noticed a
>>>>>>> discrepancy between proton-c and proton-j. With proton-c, we are
>>>>>>>able
>>>>>>> to establish 2-way authentication via SSL but with proton-j that is
>>>>>>> unsuccessful. We opened a JIRA on this yesterday but figured we'd
>>>>>>>ping
>>>>>>> the lists as well.
>>>>>>>
>>>>>>> Below is the output from our test connecting to the dispatch router
>>>>>>> configured for 2-way SSL auth.
>>>>>>>
>>>>>>>
>>>>>>> 1.
>>>>>>> 2. Client Error Message: from the log file
>>>>>>> * AMQP framing error
>>>>>>> * EventImpl{type=TRANSPORT_ERROR, context=TransportImpl
>>>>>>>
>>>>>>>[_connectionEndpoint=org.apache.qpid.proton.engine.impl.ConnectionIm
>>>>>>>pl@6e
>>>>>>> f351a0, org.apache.qpid.proton.engine.impl.TransportImpl@44c213d9]}
>>>>>>> 3. Server Error Message: from the log file
>>>>>>> *
>>>>>>>
>>>>>>> =64, totalFreeToHeap=0, transferBatchSize=64,
>>>>>>> type=org.apache.qpid.dispatch.allocator, typeName=qd_timer_t,
>>>>>>> typeSize=56)
>>>>>>>
>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (info) Activating management agent
>>>>>>>on
>>>>>>> $management
>>>>>>>
>>>>>>> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address
>>>>>>>Registered:
>>>>>>> $management
>>>>>>>
>>>>>>> Wed Mar 30 12:00:47 2016 ROUTER (info) In-Process Address
>>>>>>>Registered:
>>>>>>> $management
>>>>>>>
>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
>>>>>>> FixedAddressEntity(bias=closest, fanout=single,
>>>>>>>identity=fixedAddress/0,
>>>>>>> name=fixedAddress/0, prefix=/,
>>>>>>> type=org.apache.qpid.dispatch.fixedAddress)
>>>>>>>
>>>>>>> Wed Mar 30 12:00:47 2016 ROUTER (info) Configured Address: prefix=/
>>>>>>> phase=0 fanout=QD_SCHEMA_FIXEDADDRESS_FANOUT_SINGLE
>>>>>>> bias=QD_SCHEMA_FIXEDADDRESS_BIAS_CLOSEST
>>>>>>>
>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
>>>>>>> ListenerEntity(addr=0.0.0.0, authenticatePeer=True,
>>>>>>> certDb=/home/vsharda/protected/pprootca_cert.pem,
>>>>>>> certFile=/home/vsharda/protected/generic_cert.pem,
>>>>>>> identity=listener/0.0.0.0:20009, idleTimeoutSeconds=16,
>>>>>>> keyFile=/home/vsharda/protected/generic_key.pem,
>>>>>>>maxFrameSize=65536,
>>>>>>> name=listener/0.0.0.0:20009, password=pn2.GmdXmkKv.X7fPq.oYDFj8Cs,
>>>>>>> port=20009, requireEncryption=True, requireSsl=True, role=normal,
>>>>>>> saslMechanisms=EXTERNAL, stripAnnotations=both,
>>>>>>> type=org.apache.qpid.dispatch.listener)
>>>>>>>
>>>>>>> Wed Mar 30 12:00:47 2016 CONN_MGR (info) Configured Listener:
>>>>>>> 0.0.0.0:20009 proto=any role=normal
>>>>>>>
>>>>>>> Wed Mar 30 12:00:47 2016 SERVER (trace) Listening on 0.0.0.0:20009
>>>>>>>
>>>>>>> Wed Mar 30 12:00:47 2016 AGENT (debug) Add entity:
>>>>>>> ConsoleEntity(identity=console/0, name=console/0,
>>>>>>> type=org.apache.qpid.dispatch.console, wsport=5673)
>>>>>>>
>>>>>>> Wed Mar 30 12:00:47 2016 SERVER (info) Operational, 4 Threads
>>>>>>>Running
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (debug) Accepting incoming
>>>>>>>connection
>>>>>>> from 10.225.90.106:51196 to 0.0.0.0:20009
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) Configuring SSL on incoming
>>>>>>> connection from 10.225.90.106:51196 to 0.0.0.0:20009
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Server SSL socket
>>>>>>>created.
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:SSL/TLS connection
>>>>>>>detected
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl( data
>>>>>>> size=162 )
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Wrote 162 bytes to BIO
>>>>>>> Layer, 0 left over
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Detected read-blocked
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl()
>>>>>>> returning 162
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Read 3651 bytes from
>>>>>>>BIO
>>>>>>> Layer
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>> returning 3651
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>> returning 0
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>> returning 0
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>> returning 0
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_output_ssl()
>>>>>>> returning 0
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:process_input_ssl( data
>>>>>>> size=205 )
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:Wrote 205 bytes to BIO
>>>>>>> Layer, 0 left over
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:ERROR
>>>>>>> amqp:connection:framing-error SSL Failure: error:140890C7:SSL
>>>>>>> routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a
>>>>>>>certificate
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]: <- EOS
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]: -> EOS
>>>>>>>
>>>>>>> Wed Mar 30 12:01:06 2016 SERVER (trace) [1]:SSL socket freed.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Jack
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>>>>>> For additional commands, e-mail: users-help@qpid.apache.org
>>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org