Thank you for this informative answer. This response definitely gives me direction for resolving this problem. My work was just a POC for feasibility, and the ssl stuff was the last thing on the list to try, so my time box is up. My immediate take away is that there is not a simple thing to change to make this work. I am afraid I will have to get back to this later. Again thank you very much for the information and suggestions.
Regards -----Original Message----- From: Edward Ned Harvey (mono) [mailto:[email protected]] Sent: Friday, October 03, 2014 4:56 AM To: Brian Cole; [email protected] Subject: RE: Trouble establishing client authenticated ssl connection to ActiveMQ using NMS > From: [email protected] [mailto:mono-list- > [email protected]] On Behalf Of Brian Cole > > I am new to this list so I apologize if this post is off topic. Not off topic. Perfect place to ask. > Apache.NMS.ActiveMQ library. I am trying to create a client > authenticated ssl connection to ActiveMQ. The connection string I am > using is Does Apache.NMS ActiveMQ test their assembly on mono? The reason I ask is, mono SSL is a little bit perilous - Deep down, everything has to use SslStream which is known to have its own landmines that you have to dance around, so anything that wraps around it needs to be careful. (Typical failures are as you've seen - some useless exception is thrown and you're left wondering what the hell went wrong.) In your case, it sounds like you're experimenting with a self signed cert. But are you planning to use a real cert moving forward? I encourage you to test both, because ... like I said ... you just need to test. I was surprised how many places I needed to tweak something in order to get SSL working. Here's what you need to do: Whether in your code, or in Apache's code, find precisely where and how the server and client connections are attempting to be created. And then, probably, need to tweak the constructor in some way, or change slightly the way it's being used. Check the mono compatibility pages. Specifically the class status page: http://go-mono.com/status/ For example, System.Net.Security.SslStream has three broken ctor's. If you specify userCertificateValidationCallback, your SslStream won't work. Instead, you need to use the base ctor and see if it passes the validation process... and if it fails, then reconstruct using one of the ctor's that includes userCertificateValidationCallback, but ignore the parameters passed into your method because they're bogus, and make your acceptance decision based on something else. You mentioned certmgr. I don't know what that is, but I know if it did what you think it did, you'll find stuff under ~/.config/.mono I know mozroots can be used to implant stuff there. Not sure about certmgr. When your user account was brand new, ~/.config/.mono didn't exist. So it's safe for you to test by blowing away that directory, and then repeating your certmgr (or mozroots) command, and look in there to see what it did. PS. By default, mono has *no* trusted root CA's. If you want to trust some commonly trusted CA's, you should use "mozroots --import --sync" and if you want to trust some other CA, man mozroots _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
