Building OpenSSL for x86 and x64 on Windows for side by side deployment

| 9 Comments
The Server Framework's OpenSSL Option Pack integrates OpenSSL with my high performance server tool kit and gives you an IOCP based client or server that can handle many thousand concurrent connections with very few threads. The OpenSSL Option Pack has been around for over 10 years now and, as well as the SChannel Option Pack provides an easy way to add SSL or TLS to your clients and servers.

The one problem with OpenSSL is building new releases. It's probably just me, but I like to have both x86 and x64 libraries in the same directory with different names and I like to have just the bare minimum of headers and libraries as a simple "distributable" that I can hand to new clients if they'd rather skip the tedium of building it themselves. New releases happen frequently enough to be annoying and infrequently enough for me to forget the magic required to build things the way I like them; so I've scripted the process.

The x86 build is pretty straight forward but you need to set up paths for the compiler, and for perl, and you need to run the OpenSSL configure script correctly and then call the correct build script... Once that's done I then do the same again but for the debug versions. Then some file copying gives me a tree which includes just the include files and the libraries rather than all of the source and objects. The scripts for the 0.9.x releases and the 1.0.x releases are slightly different as the 1.0.x releases are slightly more complex as they also need NASM.

In typical "this code is from a unix background and the Windows version is always a bit of an afterthought" style, the makefiles that come with OpenSSL assume you want either x86 or x64 but not both. Given how I build software I find it better to have a single side-by-side installation of both x86 and x64 libraries and so this means that we need to massage the makefiles a little; first so that we can build to separate output directories for x64 (for when you need a build tree with both sets of objects) and second so that we have libraries with different names to the x86 libs (I went for ssleay64 and libeay64 rather than the "32" versions for x86). I use ssed for this and create new makefiles with the various settings changed.

Updated 11 September 2012 I've added some more post processing of the makefiles to generate pdb files for all builds, call them something sensible, and copy them to the minimal deploy directory structure along with the libs.

Finally I build a zip file for the compiled distribution so that it's easy for me to install and make available to clients who would like it. That script is pretty simple, but saves me having to think.

  • The scripts for the 0.9.x releases of OpenSSL can be downloaded from here.
  • The scripts for the 1.0.x releases of OpenSSL can be downloaded from here.

As is usually the way with my blog postings, this entry is mainly for me so that when I next forget how to do this, or can't find the scripts, I can search the internet with Google and get a hit for how to do it...

9 Comments

These may just be the scripts I need - thanks. However, I'm somewhat new to using OpenSSL and building it so I'm stuck right now because the scripts use something called ssed. What is that? SED? I use ActivePerl and don't seem to have ssed anyplace.

SSED is Super SED, can't remember where I got it from, but it looks like you can get it from here - https://launchpad.net/ssed/

Sorry, didn't realise that the scripts weren't complete in themselves.

Do you have a script compatible with OpenSSL-Fips? I tried modifying the ones you provided but for some reason I'm getting linking failures. Being a newbie sucks right now...

Another question. Have used output from the Windows APIs as input to OpenSSL? The only way I see to do it is if I can either get the salt value or the IV and Key. So far, every attempt to get the salt or IV always returns a bunch of 0s and the KEY is too long unless I use something similar to http://support.microsoft.com/kb/228786.

They the KEY is the right length but without the IV, I can't get OpenSSL to decrypt anything from Windows - hence my ideal to just try and build an OpenSSL library I can use.

I've never had to build the Fips stuff, so no, sorry. I would expect the process to be somewhat similar and that it simply includes different protocols.

The kb article link seems to be broken. I'm not sure exactly what you mean. I've certainly had MS SChannel code speaking to OpenSSL via SSL/TLS if that's what you mean.

It's http://support.microsoft.com/kb/228786 - no period after the URL.

When I tried the OpenSSL-FIPS-2.0.2 source code I got all sorts of build errors - mostly about missing files. I suspect it may not be as robust as the normal OpenSSL code.

Anyway, I was able to build the .LIB files and stuff using the 1.0.1e sources - so that's a bonus.

As far as WinCrypt and OpenSSL, I'm looking to generate an excrypted file and have OpenSSL (the stand alone app on Unix) decode it. It has nothing to do with SSL/TLS as we have private method of transporting the file from the PC to the Unix box.

On the Unix side, we're planning on doing something like 'openssl aes-256-cbc -in test.enc -out test.dat -d -md sha1 -a -salt'. This is for our proof of concept.

Since I can't get WinCRYPT to play correctly, I'm hopeing I can do the same thing with the openssl libs.

Anyway, back to OpenSSL. I am using the 1.0.1e sources and ran the build64.bat. The problem I see is the DLLs created are 32bit dlls that have renamed with 64 on them. They aren't true 64bit dlls.

Depency walker reports this for libeay64.dll:
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

And ssleay64.dll reports libeay32.dll is missing.

Any ideas as to why the 64bit versions aren't correcly building?

Depends sometimes gets it wrong - usually looking at x86 libs on an x64 box will give those kinds of errors.

You do have the x64 tool chain installed? You have to check some boxes that aren't always checked by default when you install the compiler.

And, well, the scripts work fine for me...

Leave a comment