more fun with ssl (connecting to an MQ Queue Manager)

Ok, this time I was trying to make a client connection to an MQ server using SSL.

If you google for how to do this, most of the hits will show you how to do it with code similar to this:

System.setProperty("", "<keystoreFilename>");
System.setProperty("", "<keystorePassword>");

System.setProperty("", "<truststoreFilename>");
System.setProperty("", "<truststorePassword>");

The crux of this is that you specify a specific file for your keyStore and trustStore (they may be the same file). The same effect can be achieved by passing these values in as parameters to the JVM with<keystoreFilename>, etc.

The problem here is that when you do this, you are setting these values for the entire JVM.

Moreover, many of the MQ docs you come across will tell you to specify the socket factory (more on the SocketFactory later) for the MQ connection by setting the MQEnvironment.sslSocketFactory static variable. Again, setting a static variable is going to affect all MQ connections you make, and this isn’t always what you want. In fact, I would have thought that most of the time, you wouldn’t want this.

What if you needed to use a specific keyStore/trustStore, and the resulting SSLSocketFactory only for one particular connection/session? The answer is to create the SSLSocketFactory using the keystore/truststore, and then pass it to the MQQueueManager constructor like so:

KeyStore ks = KeyStore.getInstance("JKS");
ks.load(new FileInputStream("/path/to/keystore"), "password".toCharArray());

KeyManagerFactory kmf = KeyManagerFactory.getInstance(KeyManagerFactory.getDefaultAlgorithm());
kmf.init(ks, "password".toCharArray());

KeyStore ts = KeyStore.getInstance("JKS");
ts.load(new FileInputStream("/path/to/truststore"), "password".toCharArray());

TrustManagerFactory tmf = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());


SSLContext sslContext = SSLContext.getInstance("SSL");
sslContext.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);

Hashtable props = new Hashtable();
props.put(MQConstants.SSL_SOCKET_FACTORY_PROPERTY, sslContext.getSocketFactory());

// ccdt is a that points to a client channel definition table file
MQQueueManager manager = new MQQueueManager(managerName, props, ccdt);

So we create a new SocketFactory, and use it to instantiate an MQQueueManager. Doing it this way doesn’t affect any other code in this JVM that may wish to use the default keyStore/trustStore, or any connections to a different Queue Manager.

Posted in Uncategorized | Leave a comment peer not authenticated – even with seemingly valid certificate

Hopefully this might help someone out, because 99% of the hits that come up when googling this java error bring you to someone telling you how to bypass certificate verification when testing with self-signed or other bad certificates. But if you’re getting this error from a website that seems to have a good certificate (e.g., you can go there with your browser and it doesn’t complain), then here’s a possible explanation.

In my case, it turns out that the problem is with the intermediate certificate in the cert chain. If you examine the certificate in your browser, you can see the entire chain. Well, the intermediate cert in the chain had a "CN = VeriSign Class 3 International Server CA - G3". Presumably most browsers have this cert in their keystore already, and therefore don’t complain that the cert is invalid. But the java installation I was using did not have this cert, and therefore couldn’t build the certificate chain.

To see that more closely, I put on ssl debugging by adding when starting the JVM, and the root error said " PKIX path building failed: unable to find valid certification path to requested target". This is at least better than “peer not authenticated”.

You can also go to verisign and use their certificate checker here. In the java applet they have there, put in the server name with the certificate in question. In my case, it did indeed report a status of “Invalid Chain”.

So even verisign’s own checker did not recognize the chain as valid due to the missing intermediate cert. The webserver should actually supply the intermediate cert along with its own cert, and then the client can verify it because the root cert (in this case, “VeriSign Class 3 Public Primary Certification”) pointed to by the intermediate cert is by default recognized by java.

So what to do? Well, really, the administrators of the webserver should fix the configuration so that the entire chain is valid. But barring that, if you really must get around the error and don’t want to use the dummy trust manager (which you should of course not do in a production environment), you can import the intermediate certificate into your java installation’s keystore. Export it using your browser (make sure you export the offending intermediate cert), then import it into your java keystore like so:

cd C:\Program Files\Java\jre6\lib\security
keytool -import -file "C:\VeriSignClass3InternationalServerCA-G3.crt" -keystore cacerts

“cacerts” is the file that contains all the trusted certificates for the java installation. You can verify which cacerts file your java installation is using by using the aforementioned JVM switch to debug ssl (, it will display the trustStore it is using. The filename “C:\VeriSignClass3InternationalServerCA-G3.crt” is what I exported from my browser.

Posted in Uncategorized | Tagged , , , , , , | 1 Comment

VMWare ESXi 5: importing a virtual machine

I was new to ESX, having only used Server/Player before. So I wasn’t quite sure how to import existing virtual machines into ESXi, and when I googled it, everyone seemed to be saying I had to use Converter to convert the vm and use the ESXi server as the target.

That does work, but as it turns out, I don’t think it’s necessary. I turned on ssh on the server and just copied the existing Server/Player VM into the datastore area. Then in the infrastructure client, I simply browsed the datastore and added the .vmx file that way. It seems to be working, although I did have to remove and re-add the network adapters.

Posted in Uncategorized | Leave a comment

mythbuntu 11: “an attempt to configure apt to install additional packages from the cdrom failed”

Because the machine I want to install mythbuntu on doesn’t have a cd drive, I thought I’d just use unetbootin to make a bootable USB stick from the iso (mythbuntu-11.10-desktop-amd64.iso). It boots and seems to install but at the end I get this error message.

Then after reboot it just hangs after the BIOS screen, with a blinking cursor in the upper left hand corner of the screen. It never starts booting the OS.

This problem seems to be related to this bug:

Currently trying the workaround, having issues even with that.

Posted in Uncategorized | Tagged , , , | Leave a comment

Hello world!

The main purpose of this blog is to try to find answers to questions I have that, upon googling them, I simply refuse to believe that no one else has also wondered about online. Questions like: Why does virtually everyone generally comply with the “no lane changing” rule in the Holland and Lincoln tunnels? It seems to me that on no other road in the state or perhaps country, would people bother paying any attention to this rule, yet when driving through these tunnels, almost no one ever changes lanes.

It boggles the mind.

Oh, and I’m not going to change the title of this post, which WordPress helpfully created for me upon creating this blog.

Posted in Uncategorized | Tagged , , , , | Leave a comment