Crypt::SSLeay and Ubuntu 11.10

Update 2: If you’re seeing this error, grab the new version of Crypt::SSLeay, version 0.60 has been released which should solve this version. For more details see the blog post announcing it’s release.

If you need to install Crypt::SSLeay on Ubuntu 11.10 and it fails with errors complaining it can’t load it might be RT 70565 hasn’t been patched yet.

#     Tried to use 'Net::SSL'.
#     Error:  Can't load '/home/user/.cpanm/work/1319487963.639/Crypt-SSLeay-0.58/blib/arch/auto/Crypt/SSLeay/' for module Crypt::SSLeay: /home/user/.cpanm/work/1319487963.639/Crypt-SSLeay-0.58/blib/arch/auto/Crypt/SSLeay/ undefined symbol: SSLv2_client_method at /home/user/perl5/perlbrew/perls/perl-5.14.1/lib/5.14.1/x86_64-linux/ line 190.

Luckily there is a patch attached to the case, nossl2.patch which can be applied to make it just work.

If you’re using cpanm, run it in prompt mode and look at the errors when they occur. That will allow you to patch the module and get it working again.

$ cpanm Crypt::SSLeay --prompt
--> Working on Crypt::SSLeay
Fetching ... OK
Configuring Crypt-SSLeay-0.58 ... OK
Building and testing Crypt-SSLeay-0.58 ... FAIL
Testing Crypt-SSLeay-0.58 failed.
You can s)kip, r)etry, f)orce install or l)ook ? [s] l
Entering /home/user/.cpanm/work/1319488454.2107/Crypt-SSLeay-0.58 with /bin/bash
$ patch < ~/Downloads/nossl2.patch
patching file SSLeay.xs
$ make
$ make test
$ exit
You can s)kip, r)etry, f)orce install or l)ook ? [s] r
Successfully installed Crypt-SSLeay-0.58

The failures aren’t really any ones fault, it’s simply that things move on. I’m assuming the module will be patched soon and this blog post will become redundant. Until then hopefully this helps people find the RT case with the solution.

Update: Torsten Raudssus has just pointed out that there is a development version that appears to fix the problem. Check the CPAN page to see if it’s still the latest, but assuming it is install it like this. Note that when it’s released, it will probably be version 0.59. The _nn part gets dropped when it’s released.

cpanm NANIS/Crypt-SSLeay-0.59_03.tar.gz

Once the developer is happy with the patch and has released it, you should be able to go back to simply installing it with cpanm Crypt::SSLeay as usual. The development release means that until it is ready for the prime time, that installing the module without specifying the version number will pick up the previous release, 0.58. I’ll try to update this post again when I notice that it has been released.


SSL host checking and LWP::UserAgent

I needed to turn on host validation and coincidentally the new major release of LWP::UserAgent does that by default now!  The one problem I had was that there wasn’t a root certificate I needed included in it’s standard bundle (well the Mozilla one in the Mozilla::CA dist).  I already suspected that would be the case since I’d noticed Firefox didn’t like the sites certificate so I just had to figure out how to authenticate this site.

Looking at the certificate I could see that it was provided by ‘GlobalSign’ so I had a look on their website for the root certificates I’d need.  They provided it in what they call their ‘Domain root validation bundle’.

These seem to be normally in the format of base64 text encapsulated by ‘—–BEGIN CERTIFICATE—–’ and headers ‘—–END CERTIFICATE—–’.  This seems to be the format of the .pem files LWP::UserAgent wants to use.  There can actually be multiple certificates in a single file as there is in the case of the bundle from GlobalSign.

If you save them to bundle.pem this little snippet will just check you can download a url from a site correctly.

require LWP::UserAgent;
my $ua = LWP::UserAgent->new;
$ua->ssl_opts( SSL_ca_file => './bundle.pem' );
my $response = $ua->get('https://somesite/');
print "URL check ", $response->is_success ? 'succeeded' : 'failed', "\n";

If you’re using your own certificate you should be able to use your own *cert.pem file in place of the bundle.pem.  In the case of for example I was able to download the cert by exporting it via Chrome and point to it in the same manner. 

That solved my problem although as I was investigating this some more I must confess this doesn’t look like the whole story in some ways.  A look at the GlobalSign site suggests they are supported by Mozilla (and Firefox) which confuses things a little.  It appears there are different types of certificate they issue and the ones I’m having to deal with aren’t included in that deal?

One additional note, if your LWP::UserAgent is deeply embedded in something else and you can’t get to it to set the config there are environment variables you can use instead.  Just check the documentation for LWP::UserAgent.