Unbuckling the safety belts

In the last year or three, many programming languages, libraries, browsers and applications have been getting stricter and stricter about how they handle and accept SSL certificates.

Of course, this is due to more and more exploits showing up in the wild. So now, formerly acceptable actions are getting warnings, and former warnings are causing code exceptions.

This pain is especially felt with self-signed certificates. Many products, or systems just generate a generic self-signed cert that is not necessarily signed to the full hostname of the end system. Almost universally, these updates outright refuse to accept this situation.

This is a regular headache for the overworked operations engineer and sysadmin. Many of the management consoles on modern equipment are inevitably a java application or a web interface. And many companies do not have the money to sit there and purchase full SSL certificates for each machine. And that assumes that you can change the certificate out.

I realize that is a long preamble, but I want people to realize the situation that is at hand. In many cases you are stuck from being able to automate or access the consoles or controls of your own servers by these changes.

It’s a long way to explain that there are times and places you find yourself needing to disable SSL validation. And for the other folks who have run into this, this is why I am writing this out.

If you’re really sure this is your only option. Here’s how to do this.

Java Applications

For Java, the answer was buried in Oracle’s documentation: http://docs.oracle.com/cd/E13222_01/wls/docs70/secmanage/ssl.html

When they started to require hostname validation, they also provided a way to turn it off. On the command line (or in app server settings) you can set the following parameter:


Java Web Consoles

When you launch a console from something like a UCS Manager or an IBL Bladecenter it often provides you with a JNLP file that is associated with the “Java Web Start” binary “javaws.” Usually your web browser downloads this file and opens it with javaws as an external viewer. Or it uses a plugin.

To force this to work, save the JNLP file onto your file system. And edit it in your favorite text editor. It is basically an XML file that describes how to launch the application and with what resources.

In the “j2se” section of the “resources” block there is a command line option called “java-vm-args.” These are the exact same command line type arguments you would pass to the standard java binary. Just add the same parameter as above. Save the file, and launch it with javaws.

Perl Applications

I do a lot of automation work in Perl. Often I am using high-level libraries like WWW::Mechanize, LWP, Soap::Lite, etc that is doing a lot of the basic web work for me. They, in turn, call the libraries that handle the SSL validation as part of that work.

As with everyone else, SSL implementations in Perl have begun refusing self-signed certificates. Thankfully, there is a way to work around this issue without having to deal with any intermediate modules that are calling SSL. You can set environment variables that are then read by the SSL modules when instanced.

Setting the following variable at the beginning of your program may solve any validation problems you have:


I had to say “may solve” in the above example because there are several SSL implementations available in Perl and not all of them check for this variable.

Personally, I ran into this at one point with Soap::Lite, which uses LWP for it’s web work and LWP can work with several different SSL libraries, depending on what is available in the OS.

To make things functional, you can tell LWP which SSL driver you wish to use. And they do this via another environment variable:


Setting those two lines seems to clean up all the situations I have run into in Perl.

As with any solution someone blogs about, “your mileage may vary.” But hopefully this helped someone else out.

Leave a Response