Build OpenVPN with specific OpenSSL version

Below is the procedure I used to build OpenVPN with OpenSSL 1.0.2. OpenSSL 1.0.1 vs. 1.0.2 vs. 1.1.0 should not matter. However, some Configure scripts dies on OpenSSL 1.1.0 because 1.1.0 uses OPENSSL_init_ssl rather than SSL_library_init. Note the use of RPATH's on Linux (OS X would use a different technique).

OpenSSL configuration options are mostly documented at Compilation and Installation | Configure Options on their wiki. I did not find similar for OpenVPN, and ./configure --help was not very helpful. Often, for an Autools project, you need to --with-ssl=<path to ssl root>, but OpenVPN does not appear to have that option. For OpenVPN, the process below went adhoc using Autools CFLAGS.

Both libraries disabled compression because it can leak information. For more details, see Spot me if you can: Uncovering spoken phrases in encrypted VoIP conversations. The problem is the variable bit rate encoding, and the fundamental design is prevalent in other compression libraries (like zlib).

OpenSSL 1.0.2

$ wget https://www.openssl.org/source/openssl-1.0.2h.tar.gz$ tar xzf openssl-1.0.2h.tar.gz$ cd openssl-1.0.2h$ ./config shared no-ssl2 no-ssl3 no-comp enable-ec_nistp_64_gcc_128 -Wl,-rpath=/usr/local/ssl/lib --prefix=/usr/local/ssl$ make -j 4$ make test$ sudo make install# clear program cache$ hash -r

You can check the openssl program is using the expected shared objects with:

$ ldd /usr/local/ssl/bin/openssl    linux-vdso.so.1 =>  (0x00007ffc36578000)    libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0 (0x00007f94b48fb000)    libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x00007f94b448b000)    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f94b40c6000)    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f94b3ec2000)    /lib64/ld-linux-x86-64.so.2 (0x00007f94b4b6c000)

You can also make sure the new openssl is on-path with the following. Its not required for your issue, however.

$ sudo ln -s /usr/local/ssl/bin/openssl /usr/local/bin/openssl$ hash -r$ command -v openssl/usr/local/bin/openssl

OpenVPN 2.3.11

$ wget https://swupdate.openvpn.org/community/releases/openvpn-2.3.11.tar.gz$ tar xzf openvpn-2.3.11.tar.gz$ cd openvpn-2.3.11$ CFLAGS="-I/usr/local/ssl/include -Wl,-rpath=/usr/local/ssl/lib -L/usr/local/ssl/lib" ./configure --disable-lzo$ make -j 4

Next, check the OpenVPN program to see what its linking to:

$ find . -type f -name openvpn./src/openvpn/openvpn$ ldd ./src/openvpn/openvpn    linux-vdso.so.1 =>  (0x00007ffc8bfc4000)    libssl.so.1.0.0 => /usr/local/ssl/lib/libssl.so.1.0.0 (0x00007f74f49f3000)    libcrypto.so.1.0.0 => /usr/local/ssl/lib/libcrypto.so.1.0.0 (0x00007f74f4583000)    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f74f437f000)    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f74f3fba000)    /lib64/ld-linux-x86-64.so.2 (0x00007f74f4c64000)

Next, run the self tests:

$ make check...make[3]: Entering directory `/home/jwalton/openvpn-2.3.11/tests'./t_client.sh: cannot find 't_client.rc' in build dir ('..')./t_client.sh: or source directory ('.'). SKIPPING TEST.SKIP: t_client.shTesting cipher AES-128-CBC... OKTesting cipher AES-128-CFB... OKTesting cipher AES-128-CFB1... OK...

Install OpenVPN if it tests OK:

$ sudo make install$ hash -r$ command -v openvpn/usr/local/sbin/openvpn

Finally, check it:

$ /usr/local/sbin/openvpn --versionOpenVPN 2.3.11 x86_64-unknown-linux-gnu [SSL (OpenSSL)] [EPOLL] [MH] [IPv6] built on Aug 17 2016library versions: OpenSSL 1.0.2h  3 May 2016Originally developed by James YonanCopyright (C) 2002-2010 OpenVPN Technologies, Inc. <sales@openvpn.net>...

If interested, you can find a build script to automate the process at Noloader | Build-Scripts. It includes one for OpenVPN.

OpenVPN reports the version of the runtime library, so what you are seeing here is linking/dynamic library behaviour. Probably your ld.so.conf is setup to prefer /usr/lib/.so over /usr/local/lib/.so

One solution I have successfully used is the OpenVPN build-system

Simply change the OpenSSL source version in generic/build.vars and let it go (as documented)

If you have trouble with options like --dynamicbase or --nxcompat then also disable those flags in generic/build.vars