Help using CA signed certificates with a Qpid Proton C++ app

[Shipley, Glen]

Hi All,

I need help on using CA signed certificates with a Qpid Proton C++ app and an 
ActiveMQ broker for SSL.

I have in /home/user/cert_dir the following -

rootCACert.pem
broker-signedcert.pem
client-signedcert.pem
client-key.pem
password

The password file just contains password which is the password used for all.

I then ran the following commands to set up the certificate database -

certutil -N -d /home/user/cert_dir -f /home/user/cert_dir/password
certutil -A -i broker-signedcert.pem -d /home/user/cert_dir -f 
/home/user/cert_dir/password -n broker -t "P"
certutil -A -i rootCACert.pem -d /home/user/cert_dir -f 
/home/user/cert_dir/password -n root -t "TC"

I kick off the broker by running the following script -
setenv JAVA_HOME /programs/Java/jdk1.8.0_121
setenv PATH ${JAVA_HOME}/bin:${PATH}
setenv ACTIVEMQ_SSL_OPTS "-Djavax.net.ssl.keyStore=/pki/broker.ks 
-Djavax.net.ssl.keyStorePassword=password 
-Djavax.net.ssl.trustStore=/pki/broker.ts 
-Djavax.net.ssl.trustStorePassword=password -Djavax.net.debug=ssl"
./activemq console

I have confidence that the broker is not the problem because I can run -
openssl s_client -connect localhost:5671 -showcerts -cert 
/home/user/cert_dir/client-signedcert.pem -key 
/home/user/cert_dir/client-key.pem -pass pass:password -CAfile 
/home/user/cert-dir/rootCACert.pem

which returns a verify code of 0 (ok). If I leave off the -CAfile it returns 
with a verify code of 19 (self signed certificate in chain). I can see in the 
broker window that the SSL handshake completed. When from the s_client I try to 
send a message, the broker closes the connection with the broker logging - WARN 
| Connection attempt from non AMQP v1.0 client.


My qpid proton app code has -
void on_container_start(proton:container )
{
   std:cout << "-INFO- on_container_start -" << std::endl;
   proton::ssl_certificate certificate("/pki/client-signedcert.pem", 
"/pki/client-private.pem", "password");

   proton::ssl::verify_mode = proton::ssl::VERIFY_PEER_NAME;

   proton::ssl_client_options sslClientOptions(certificate, 
"/pki/broker-signedcert.pem", ssl_verify_mode);

   proton::connection_options connectionOptions;
   connectionOptions.ssl_client_options(sslClientOptions);
   connectionOptions.virtual_host("broker"); // this is the CN of the broker 
certificate
   connectionOptions.idle_timeout(proton::duration::FOREVER);

   c.client_connection_options(connectionOptions);

   c.connect("localhost:5671", connectionOptions); // broker runs on same 
machine
}

I launch the client code with a script that has
export QPID_SSL_CERT_DB="/home/user/cert_dir"
export QPID_SSL_CERT_PASSWORD_FILE="/home/user/cert_dir/password"


Client CA signed certificates (fails)
SSL:TRACE:Client SSL socket created.
EVENT:DEBUG:(PN_CONNECTION_INIT, pn_connection<0x82107e8>
EVENT:DEBUG:(PN_CONNECTION_BOUND, pn_connection<0x82107e8>
SSL:TRACE:Gathered 8 bytes from app to send to peer
SSL:TRACE:Detected read-blocked
SSL:TRACE:Wrote 280 bytes to BIO Layer, 0 left over
SSL:TRACE:Detected read-blocked
SSL:TRACE:process_output_ssl() returning 0
SSL:TRACE:Detected read-blocked
SSL:TRACE:process_output_ssl() returning 0
SSL:TRACE:process_input_ssl( data size=3695 )
SSL:TRACE:Wrote 3695 bytes to BIO Layer, 0 left over
AMQP:ERROR:amqp:connection:framing-error SSL Failure error:14090086:SSL 
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Broker CA signed certificates
*** ServerHelloDone
ActiveMQ Transport: ssl:///192.168.107.206.45206, WRITE: TLSv1.2 Handshake, 
length = 3690
ActiveMQ Transport: ssl:///192.168.107.206.45206, received EOFException: error
ActiveMQ Transport: ssl:///192.168.107.206.45206, handling exception: 
javax.net.ssl.SSLHandshakeException: Remote host closed connection during 
handshake

Can anyone help with what I need to do differently?

Thanks,
Glen




The preceding message (including attachments) is covered by the Electronic 
Communication Privacy Act, 18 U.S.C. sections 2510-2512, is intended only for 
the person or entity to which it is addressed, and may contain information that 
is confidential, protected by attorney-client or other privilege, or otherwise 
protected from disclosure by law. If you are not the intended recipient, you 
are hereby notified that any retention, dissemination, distribution, or copying 
of this communication is strictly prohibited. Please reply to the sender that 
you have received the message in error and destroy the original message and all 
copies.

Re: Qpid C++ Broker Segfault

[Gordon Sim]

On Fri, Jan 14, 2022 at 10:36 AM Pete Fawcett  wrote:
> I tried this but it didn't, initially, fix the problem.
> It turns out that the current exception handling is causing the link to be
> closed from within Connection object doDeliveryUpdated
> 
> Calling Session::abort_pending() from there meant changing abort_pending()
> to be a public function, which makes me wonder if it is the right thing to
> be doing.
> Making the change, and calling abort_pending() before closing the link in
> doDeliveryUpdated, did remove the pending items and so prevent the Segfault.

You could also put a try/catch in Session::readable[1], and call
abort_pending before rethrowing. (Or later, send back a nack for the
message instead of rethrowing for certain errors).

[1] 
https://github.com/apache/qpid-cpp/blob/main/src/qpid/broker/amqp/Session.cpp#L697


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Qpid C++ Broker Segfault

[Pete Fawcett]

On Tue, 11 Jan 2022 at 09:35, Pete Fawcett  wrote:

> Hi Gordon
>
> Thank you for the helpful response
>
> On Fri, 7 Jan 2022 at 11:18, Gordon Sim  wrote:
>
>> On Thu, Jan 6, 2022 at 8:56 PM Pete Fawcett  wrote:
>> > *Questions:*
>> >
>> > Firstly, a simple work around is to check the link pointer when moving
>> > delivery pointers from 'pending' to completed and discarding them if the
>> > 'link' is NULL . Does this suffice?
>>
>> I think that would probably work. However it would be nicer to
>> actually remove them from pending before they were invalidated. Does
>> calling abort_pending() for the link before closing it in
>>
>> https://github.com/apache/qpid-cpp/blob/main/src/qpid/broker/amqp/Session.cpp#L764
>> prevent the segfault?
>>
>
> I will try this.  Thank you for pointing out where to remove the pending
> items, I hadn't managed to figure that out.
>

I tried this but it didn't, initially, fix the problem.
It turns out that the current exception handling is causing the link to be
closed from within Connection object doDeliveryUpdated

Calling Session::abort_pending() from there meant changing abort_pending()
to be a public function, which makes me wonder if it is the right thing to
be doing.
Making the change, and calling abort_pending() before closing the link in
doDeliveryUpdated, did remove the pending items and so prevent the Segfault.

As well as being concerned about changing functions to be part of the
public interface, I would still have concerns that other cases may arise.
My instinct would be to keep my initial suggestion of checking for invalid
pending deliveries before they are actioned.  This would be in addition to
these attempts to clear the deliveries when the link closes.

I haven't yet looked at the prospect of not closing the link for the
particular case of a full queue, but I think the handling of the link error
needs to be "safe", regardless of other possible changes.


>
>
>
>> > Secondly, does the link need to be cleared just because a message is too
>> > big for the queue? Can it not be signalled back to the sender in a less
>> > drastic manner? (Dropping the link means it is likely for numerous
>> messages
>> > to be repeatedly delivered when using "at least once" delivery)
>>
>> The message could be rejected. (I think that would involve changing
>> the exception handling at
>>
>> https://github.com/apache/qpid-cpp/blob/main/src/qpid/broker/amqp/Session.cpp#L948
>> to not throw but to simply reject the message).
>>
>> I will also look at this, though I think the message should be "returned"
> rather than "rejected"
>
> It only just occurred to me that the reason there are items still pending
> is probably due to flow control - I had been thinking it was a data race -
> so I'll need to keep that in mind when attempting to return a status to the
> sender.
>
> Thanks again
>
> Pete
>
>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: users-h...@qpid.apache.org
>>
>>