Saturday, June 4, 2011

Apache.NMS.ActiveMQ v1.5.1 Released

Today marks the official release of Apache.NMS.ActiveMQ v1.5.1.  We put a lot of work into this one fixing bugs that were found since the 1.5.0 release.  The MS Distributed Transaction Support should be much more stable in this release.

For anyone on v1.5.0 I'd definitely recommend upgrading, there were a couple of threading issues that have been resolved which should make things more stable.

The v1.5.1 release page is here


Bob_Thor said...

I'm trying to get 2-way SSL to work with Apache.NMS on windows and having trouble specifying the client certificate to use. I'm sure the broker is set up because it works fine with a java client following the How to Use SSL guide on the Apache Website. Do you know of a C# client example that uses 2-way SSL certificate authentication?

Tim said...

There aren't any examples since it all really comes down to configuration. You need to ensure that your client cert is in the brokers trust store, and then specify on the SSLTransport uri option the location of the client certificate and its password, or if you have a cert loaded into the windows certificate store then you need to have the right subject name set for the client cert. Browsing the SslTransport.cs code would be instructive.

Bob_Thor said...

Is there a definition of the query parameters for the client certificate name and password? Browsing SslTransport.cs was helpful but I'm having a hard time in TcpTransportFactory.cs figuring out what keys the code is looking for to get these values.

Thanks for your time to respond!

Tim said...

It would actually be the values in the SslTransportFactory, all prefixed by transport.[option]

Bob_Thor said...

Does this look correct?


Tim said...

Well I think you only need the ClientCertPassword if you also set the ClientCertFilename options, otherwise it won't be used for anything. The MS Cert store I believe is unlocked by the user that's currently logged in.

Bob_Thor said...

I've been debugging SslTransport this afternoon and have found one of my problem is the certificate subject matching within SelectLocalCertificate. How am I supposed to encode the URI when the certificate subject looks like "CN=Client, OU=L-3 Communications, O=ComCept, L=Rockwall, S=Texas, C=US" Encoding the equal sign as %3D made it past the URI regex bu did not work in the method.

Tim said...

There's probably some .NET equivalent to the Java URI encode and decode methods for that sort of encoding, perhaps you can play around with it and come up with a patch? If so open a new Jira issue and attach the patch with Apache license grant and we can apply it in SVN.

Bob_Thor said...

Modifying this line in the DoCreateTransport method works

transport.ClientCertSubject = HttpUtility.UrlDecode(this.clientCertSubject);

but now I'm getting a handshake error as follows:

*** Certificate chain
ActiveMQ Task-7, SEND TLSv1 ALERT: fatal, description = bad_certificate
ActiveMQ Task-7, WRITE: TLSv1 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 01 00 02 02 2A ......*
ActiveMQ Task-7, called closeSocket()
ActiveMQ Task-7, handling exception: null cert chain
ActiveMQ Transport: ssl:///, handling exception: Connection has been shutdown: null cert chain
ActiveMQ Task-9, called close()
ActiveMQ Task-9, called closeInternal(true)
ERROR | Could not accept connection : null cert chain

Looks like the trust chain of the client certificate is empty. How do I send that over?

Tim said...

You need to have the Root certificate and all the intermediate signing certs in the Brokers Trust Store prior to the client sending its certificate over. If you have the Root signing cert in your trust store it should pass.

Bob_Thor said...

I don't know how to open a jira issue, but I would be glad to submit the snippet for a change. Do I work through the "become a contributor" guide?

Tim said...

Got here:

Create an account and then you can select create issue under the Issues menu.

Bob_Thor said...

I finally got it to work with the fix to the SslTransportFactory.cs patch. The trick was to make sure the client certificate on the C# side was a PKCS12 that has the private key in the CurrentUser key store. I had only installed the .cer file which only has the public key. So the following URI does work with the HttpUtility.UrlDecode fix

var cf = new ConnectionFactory(@"ssl://");

chalicham said...


I just followed all the steps(install certs in root, passing the values in URI) but i could not make it work.

When i enable trace i found following :

SecureChannel#24445403 - Client delegate did not provide a certificate; but there are other user-provided certificates".
System.Net Information: 0 : [10352] SecureChannel#24445403 - Left with 0 client certificates to choose from.

My URI as follows: ssl://localhost:61617?transport.serverName=localhost

Can some one help me how to pass the right URI here?