Re: httpd and OpenSSL 1.0.2
Hi, got it working. >From Kaspar Brand the hint[1] not to use static was very good. Thanks! Mario [1] http://mail-archives.apache.org/mod_mbox/httpd-dev/201504.mbox/%3c554072b0.40...@velox.ch%3E
Re: httpd and OpenSSL 1.0.2
Along the lines of "to be continued" - IMHO httpd should be one of the early adopters of not allowing linkage to versions of openssl that cannot support TLS1.2. I have built (on AIX) against libreSSL (v2.1.6) with some private additions for AIX (that will be verified and improved upon by openbsd in the soon to be released libreSSL 2.2 version). Basically, there are only two defines that were 'missing'. One was rather 'obscure' it what it is suppossed to be doing (i.e., looking in the openssl code) - the other was downright 'dangerous" because it permits 'any external so-called enthrophy generator' to be added and used for randomness - because it is, or at least was, part of the openSSL libraries. (the approach of libreSSL was to completely remove it, hence a missing #define). Again - to be continued. and asap - in a separate post I will post the differences to get it to link against libreSSL (p.s. only mod_ssl needs this afaik). On Wed, May 27, 2015 at 3:29 PM, Tom Browder wrote: > On May 27, 2015 5:26 AM, "Mario Brandt" wrote: > > Hi Tom, > > I saw you on the httpd dev mailing list about that topic. How did you > > manage to build apache against 1.0.2? > > > > Cause if I try that I get in my VM > > > > /opt/apache2/modules/mod_ssl.so: undefined symbol: SSL_CONF_CTX_finish > > > > or on my real server > > > > /opt/apache2/modules/mod_ssl.so: undefined symbol: SSL_CONF_CTX_free > > > > OpenSSL > > ./config --prefix=/usr zlib-dynamic --openssldir=/etc/ssl shared no-ssl2 > > make depend > > make > > sudo make install > > > > > > apache > > ./configure --prefix=/opt/apache2 --enable-pie > > --enable-mods-shared=all --enable-so --disable-include --enable-lua > > --enable-deflate --enable-headers --enable-expires --enable-ssl=shared > > --enable-mpms-shared=all --with-mpm=event --enable-rewrite > > --with-z=$HOME/apache24/httpd-2.4.12/srclib/zlib --enable-module=ssl > > --enable-fcgid --with-included-apr > > --with-openssl=$HOME/apache24/openssl-1.0.2a > > --enable-ssl-staticlib-deps > > > > with the 1.0.1m it works all fine > > seehttps:// > github.com/JBlond/debian_build_apache24/blob/master/build_apache.sh > > > > > > Please tell me how you got it working. > > Mario, I did get it working, but I did have a bit more effort to make > the latest openssl work. Taking a quick look at your blog I believe I > can help, but I'll explain my solution in a follow-up message so this > thread is on the public mailing lists. > > I feel I must explain that I'm using a Debian 7, 64-bit server. It > might help if we could know your server info as other architectures > may require more or other tweaks. > > Finally, the best I can probably do is show you my configure options > which may conflict with yours. > > TO BE CONTINUED > > Best regards, > > -Tom >
Re: httpd and OpenSSL 1.0.2
On Mon, Jun 1, 2015 at 10:22 AM, Tom Browder wrote: > Okay, here's what I had to do to my Linux Deb 7, 64-bit system: ... > 2. Source packages used (in order of installation): ... > pcre2-10.00.tar.bz2 Oops, my error: I had to use pcre-8.36 (httpd cannot yet use pcre2). Best, -Tom
Re: httpd and OpenSSL 1.0.2
On Wed, May 27, 2015 at 11:33 AM, Mario Brandt wrote: > Hi Tom, > > I tried on Debian 7 and 8 both x64 > > To see your configure options would help a lot. Okay, here's what I had to do to my Linux Deb 7, 64-bit system: 1. Remove any deb packages of httpd, apr, apr-util, openssl. 2. Source packages used (in order of installation): openssl-1.0.2a.tar.gz apr-1.5.1.tar.bz2 apr-util-1.5.4.tar.bz2 pcre2-10.00.tar.bz2 httpd-2.4.12.tar.bz2 3. Build and install: $ sudo aptitude install zlib1g-dev openssl --- export SSLDIR=/opt/openssl ./config \ no-ec2m \ no-rc5 \ no-idea \ threads \ zlib-dynamic\ shared \ --prefix=${SSLDIR} \ --openssldir=${SSLDIR} \ enable-ec_nistp_64_gcc_128 \ make depend make make test sudo make install apr ./configure --with-crypto make make check sudo make install apr-util -- ./configure --with-apr=/usr/local/apr make make check sudo make install pcre -- ./configure make make check sudo make install httpd --- \# we build all modules for now (all shared except mod_ssl) # Note that 'session_module' needs to be activated (loaded). export LDFLAGS="-Wl,-rpath,${SSLDIR}/lib" $SRCDIR/configure \ --prefix=/usr/local/apache2\ --with-included-apr\ \ --enable-ssl \ --enable-ssl-staticlib-deps\ --enable-mods-static=ssl \ --with-ssl=${SSLDIR} \ \ --enable-mods-shared=reallyall \ --with-perl\ --with-python \ --enable-layout=Apache \ --with-pcre=/usr/local/bin/pcre-config \ --without-ldap \ --enable-session-crypto\ --with-crypto \ --with-openssl=${SSLDIR} make sudo make install Notes: 1. I used both local install of apr/apr-util AND source inside httpd. 2. Note --with-crypto option for apr in local build 3. Note I have not modified my LD_LIBRARY_PATH for any of the above programs. It all works for me. Hope that helps. Best regards, -Tom
Re: httpd and OpenSSL 1.0.2
Hi Tom, since I'm mostly a windows user and sure how to debug that and wasn't successful, it would be nice if you could give me the working script. Thanks Mario
Re: httpd and OpenSSL 1.0.2
Am 29.05.2015 um 18:36 schrieb Wang, Andy: It didn't break api compatibly but it sure did break backwards compatibility. I'm pretty sure if you link against 1.0.2 you can't run with an older 1.0.x library. Which is what appears to happen in Mario's case. That's correct. If the app or lib you compile uses symbols only available in newer versions, then this is true. An example is mod_ssl. The runtime version needs to have the same SONAME and must have at least the same numeric OpenSSL version as the compile version. I'm speculating as to why - being related to improperly replacing a system package management maintained library. I don't get the "why": Why what? Why his runtime version is older than the version used during compile time? For that he would have to track down the files used. I tried to gave hints how to do that. Regards, Rainer
Re: httpd and OpenSSL 1.0.2
Am 29.05.2015 um 18:30 schrieb William A Rowe Jr: Don't be fooled. OpenSSL 1.0.1 did not break binary compatibility, the lib designation remains .so.1.0.0. Can someone confirm whether this was changed in 1.0.2? As I already wrote it didn't. Rainer
RE: httpd and OpenSSL 1.0.2
It didn't break api compatibly but it sure did break backwards compatibility. I'm pretty sure if you link against 1.0.2 you can't run with an older 1.0.x library. Which is what appears to happen in Mario's case. I'm speculating as to why - being related to improperly replacing a system package management maintained library. Andy ___ From: William A Rowe Jr [wr...@rowe-clan.net] Sent: Friday, May 29, 2015 11:30 AM To: httpd Subject: Re: httpd and OpenSSL 1.0.2 Don't be fooled. OpenSSL 1.0.1 did not break binary compatibility, the lib designation remains .so.1.0.0. Can someone confirm whether this was changed in 1.0.2? On May 29, 2015 10:26 AM, "Mario Brandt" mailto:jbl...@gmail.com>> wrote: Hi Andy, it seems that you are right. After cheking the lib I saw this -rw-r--r-- 1 root root 4,4M Mai 29 10:51 libcrypto.a lrwxrwxrwx 1 root root 18 Mai 29 10:51 libcrypto.so -> libcrypto.so.1.0.0 -r-xr-xr-x 1 root root 2,6M Mai 29 10:51 libcrypto.so.1.0.0 -rw-r--r-- 1 root root 744K Mai 29 10:51 libssl.a lrwxrwxrwx 1 root root 15 Mai 29 10:51 libssl.so -> libssl.so.1.0.0 -r-xr-xr-x 1 root root 499K Mai 29 10:51 libssl.so.1.0.0 that shows the current date, but the old version number. Mario On 29 May 2015 at 15:16, Wang, Andy mailto:aw...@ptc.com>> wrote: > You might want to reconsider that unless you really really are sure you know > what you're doing. > On a linux distro, the system installed openssl is considered a fundamental > platform infrastructure library. I.e. many many things rely on it. openssl > versions are not backward compatible. > > So if you don't rebuild all of your distro installed dependencies on openssl, > you've likedly just screwed up runtime linking of alot of things. > > Also, the system installed library and the openssl config makefiles may be > using incompatible soname mechanisms, which could explain why you're able to > link but not run (i.e. at linktime it may be finding the right library, but > at runtime it's not). > > Andy > > > From: Mario Brandt [jbl...@gmail.com<mailto:jbl...@gmail.com>] > Sent: Friday, May 29, 2015 3:57 AM > To: Tom Browder > Cc: dev@httpd.apache.org<mailto:dev@httpd.apache.org> > Subject: Re: httpd and OpenSSL 1.0.2 > > Hi Tom, > > nope setting LD_LIBRARY_PATH did not solve my problem. That is a bit > tricky since I install the new openssl version system wide > > ./config --prefix=/usr zlib-dynamic --openssldir=/etc/ssl shared no-ssl2 > > > Mario > >> -Tom
Re: httpd and OpenSSL 1.0.2
Don't be fooled. OpenSSL 1.0.1 did not break binary compatibility, the lib designation remains .so.1.0.0. Can someone confirm whether this was changed in 1.0.2? On May 29, 2015 10:26 AM, "Mario Brandt" wrote: > Hi Andy, > > it seems that you are right. After cheking the lib I saw this > > -rw-r--r-- 1 root root 4,4M Mai 29 10:51 libcrypto.a > lrwxrwxrwx 1 root root 18 Mai 29 10:51 libcrypto.so -> > libcrypto.so.1.0.0 > -r-xr-xr-x 1 root root 2,6M Mai 29 10:51 libcrypto.so.1.0.0 > -rw-r--r-- 1 root root 744K Mai 29 10:51 libssl.a > lrwxrwxrwx 1 root root 15 Mai 29 10:51 libssl.so -> libssl.so.1.0.0 > -r-xr-xr-x 1 root root 499K Mai 29 10:51 libssl.so.1.0.0 > > that shows the current date, but the old version number. > > Mario > > On 29 May 2015 at 15:16, Wang, Andy wrote: > > You might want to reconsider that unless you really really are sure you > know what you're doing. > > On a linux distro, the system installed openssl is considered a > fundamental platform infrastructure library. I.e. many many things rely on > it. openssl versions are not backward compatible. > > > > So if you don't rebuild all of your distro installed dependencies on > openssl, you've likedly just screwed up runtime linking of alot of things. > > > > Also, the system installed library and the openssl config makefiles may > be using incompatible soname mechanisms, which could explain why you're > able to link but not run (i.e. at linktime it may be finding the right > library, but at runtime it's not). > > > > Andy > > > > ________________ > > From: Mario Brandt [jbl...@gmail.com] > > Sent: Friday, May 29, 2015 3:57 AM > > To: Tom Browder > > Cc: dev@httpd.apache.org > > Subject: Re: httpd and OpenSSL 1.0.2 > > > > Hi Tom, > > > > nope setting LD_LIBRARY_PATH did not solve my problem. That is a bit > > tricky since I install the new openssl version system wide > > > > ./config --prefix=/usr zlib-dynamic --openssldir=/etc/ssl shared no-ssl2 > > > > > > Mario > > > >> -Tom >
Re: httpd and OpenSSL 1.0.2
Hi Andy, it seems that you are right. After cheking the lib I saw this -rw-r--r-- 1 root root 4,4M Mai 29 10:51 libcrypto.a lrwxrwxrwx 1 root root 18 Mai 29 10:51 libcrypto.so -> libcrypto.so.1.0.0 -r-xr-xr-x 1 root root 2,6M Mai 29 10:51 libcrypto.so.1.0.0 -rw-r--r-- 1 root root 744K Mai 29 10:51 libssl.a lrwxrwxrwx 1 root root 15 Mai 29 10:51 libssl.so -> libssl.so.1.0.0 -r-xr-xr-x 1 root root 499K Mai 29 10:51 libssl.so.1.0.0 that shows the current date, but the old version number. Mario On 29 May 2015 at 15:16, Wang, Andy wrote: > You might want to reconsider that unless you really really are sure you know > what you're doing. > On a linux distro, the system installed openssl is considered a fundamental > platform infrastructure library. I.e. many many things rely on it. openssl > versions are not backward compatible. > > So if you don't rebuild all of your distro installed dependencies on openssl, > you've likedly just screwed up runtime linking of alot of things. > > Also, the system installed library and the openssl config makefiles may be > using incompatible soname mechanisms, which could explain why you're able to > link but not run (i.e. at linktime it may be finding the right library, but > at runtime it's not). > > Andy > > > From: Mario Brandt [jbl...@gmail.com] > Sent: Friday, May 29, 2015 3:57 AM > To: Tom Browder > Cc: dev@httpd.apache.org > Subject: Re: httpd and OpenSSL 1.0.2 > > Hi Tom, > > nope setting LD_LIBRARY_PATH did not solve my problem. That is a bit > tricky since I install the new openssl version system wide > > ./config --prefix=/usr zlib-dynamic --openssldir=/etc/ssl shared no-ssl2 > > > Mario > >> -Tom
Re: httpd and OpenSSL 1.0.2
On 29 May 2015 at 16:49, Andy Wang wrote: > Yeah, I honestly wasn't really thinking that closely about it. I do know > this. > > The openssl default install results in the following: > libssl.so.1.0.0 > symlinked to > libssl.so > > however, fedora's system provided libraries look like this: > lrwxrwxrwx. 1 root root 16 Mar 19 12:37 libssl.so.10 -> libssl.so.1.0.1k > -rwxr-xr-x. 1 root root 439572 Mar 19 12:37 libssl.so.1.0.1k > > So depending on how the linker finds the library, this could be kind of a > mess. > > And I no longer have a debian system so wasn't sure how debian's system > installs are. Debian is the same. And I nevr and any issues compiling against a symlink. Cheers Mario
Re: httpd and OpenSSL 1.0.2
On 05/29/2015 09:20 AM, Rainer Jung wrote: Here you can see the SONAME is libssl.so.1.0.0. This name is added as a dependency into the linked binary. At runtime the runtime linker will look for this file, not for libssl.so. During installation of lobssl.so (resp. libcrypto.so) typically the files get linked using a symlink, so it would make no difference. If you start to overwrite parts of the system installation, the two names might point to different content. About compatibility: OpenSSL 1.0.0 up to OpenSSL 1.0.2 have compatible APIs, that's why the SONAME ends with .1.0.0 in all three cases. It is definitely possible to upgrade, i.e. use a newer version in the 1.0.0 to 1.0.2 range during runtime than was used during compile/link time. The other way round only holds for patch versions with the same first three digits. The SSL_CONF_CTX_* symbols you were originally referring to are only part of 1.0.2. So it seems you compiled against header files from 1.0.2 and likely also loinked against a 1.0.2 libssl.so, but at runtime the libssl.so.1.0.0 that the runtime linker finds is version 1.0.0 or 1.0.1. The runtime linker has a search path that is defined on the system and can be influenced using LD_LIBRARY_PATH. The compile time linker is also influenced by compile "-L" flags. Yeah, I honestly wasn't really thinking that closely about it. I do know this. The openssl default install results in the following: libssl.so.1.0.0 symlinked to libssl.so however, fedora's system provided libraries look like this: lrwxrwxrwx. 1 root root 16 Mar 19 12:37 libssl.so.10 -> libssl.so.1.0.1k -rwxr-xr-x. 1 root root 439572 Mar 19 12:37 libssl.so.1.0.1k So depending on how the linker finds the library, this could be kind of a mess. And I no longer have a debian system so wasn't sure how debian's system installs are. Also, in the past I've noticed linux distros "re-base" include headers to be in /usr/include directly vs under include/openssl where the openssl distro normally installs them. So i generally figure that the notion of replacing a distro provided openssl is just a bad bad idea unless you really really know what you're doing. Andy
Re: httpd and OpenSSL 1.0.2
Am 29.05.2015 um 15:16 schrieb Wang, Andy: You might want to reconsider that unless you really really are sure you know what you're doing. On a linux distro, the system installed openssl is considered a fundamental platform infrastructure library. I.e. many many things rely on it. openssl versions are not backward compatible. So if you don't rebuild all of your distro installed dependencies on openssl, you've likedly just screwed up runtime linking of alot of things. Also, the system installed library and the openssl config makefiles may be using incompatible soname mechanisms, which could explain why you're able to link but not run (i.e. at linktime it may be finding the right library, but at runtime it's not). I didn't follow the whole thread, but about linking versus running: at link time the linker will use the files libssl.so and libcrypto.so (or libssl.a and libcrypto.a). Because all it is given is -lssl and -lcrypto as flags. It will look in those files for an entry named SONAME. On linux you can see that name by issuing objdump -p /path/to/my/libssl.so and objdump -p /path/to/my/libcrypto.so Example output: /path/to/my/libssl.so: file format elf64-x86-64 Program Header: ... Dynamic Section: NEEDED libcrypto.so.1.0.0 NEEDED libdl.so.2 NEEDED libz.so.1 NEEDED libc.so.6 SONAME libssl.so.1.0.0 ... Version References: required from libc.so.6: 0x09691a75 0x00 02 GLIBC_2.2.5 Here you can see the SONAME is libssl.so.1.0.0. This name is added as a dependency into the linked binary. At runtime the runtime linker will look for this file, not for libssl.so. During installation of lobssl.so (resp. libcrypto.so) typically the files get linked using a symlink, so it would make no difference. If you start to overwrite parts of the system installation, the two names might point to different content. About compatibility: OpenSSL 1.0.0 up to OpenSSL 1.0.2 have compatible APIs, that's why the SONAME ends with .1.0.0 in all three cases. It is definitely possible to upgrade, i.e. use a newer version in the 1.0.0 to 1.0.2 range during runtime than was used during compile/link time. The other way round only holds for patch versions with the same first three digits. The SSL_CONF_CTX_* symbols you were originally referring to are only part of 1.0.2. So it seems you compiled against header files from 1.0.2 and likely also loinked against a 1.0.2 libssl.so, but at runtime the libssl.so.1.0.0 that the runtime linker finds is version 1.0.0 or 1.0.1. The runtime linker has a search path that is defined on the system and can be influenced using LD_LIBRARY_PATH. The compile time linker is also influenced by compile "-L" flags. Whether some specific libssl.so (or libssl.so.1.0.0) file contains the symbol or not can be checked using the "nm" command: nm /path/to/my/libssl.so1.0.0 | grep SSL_CONF_CTX Example output here: 000581a0 T SSL_CONF_CTX_clear_flags 00058180 T SSL_CONF_CTX_finish 00058250 T SSL_CONF_CTX_free 000582f0 T SSL_CONF_CTX_new 00058280 T SSL_CONF_CTX_set1_prefix 00058190 T SSL_CONF_CTX_set_flags 000581b0 T SSL_CONF_CTX_set_ssl 00058200 T SSL_CONF_CTX_set_ssl_ctx If the symbols are not contained you will get no hits, if they are only referred in the lib but contained in another depenency lib, you get a "U" marker instead of the "T" (also see the nm man page for more possible cases). HTH Rainer
RE: httpd and OpenSSL 1.0.2
You might want to reconsider that unless you really really are sure you know what you're doing. On a linux distro, the system installed openssl is considered a fundamental platform infrastructure library. I.e. many many things rely on it. openssl versions are not backward compatible. So if you don't rebuild all of your distro installed dependencies on openssl, you've likedly just screwed up runtime linking of alot of things. Also, the system installed library and the openssl config makefiles may be using incompatible soname mechanisms, which could explain why you're able to link but not run (i.e. at linktime it may be finding the right library, but at runtime it's not). Andy From: Mario Brandt [jbl...@gmail.com] Sent: Friday, May 29, 2015 3:57 AM To: Tom Browder Cc: dev@httpd.apache.org Subject: Re: httpd and OpenSSL 1.0.2 Hi Tom, nope setting LD_LIBRARY_PATH did not solve my problem. That is a bit tricky since I install the new openssl version system wide ./config --prefix=/usr zlib-dynamic --openssldir=/etc/ssl shared no-ssl2 Mario > -Tom
Re: httpd and OpenSSL 1.0.2
Hi Tom, nope setting LD_LIBRARY_PATH did not solve my problem. That is a bit tricky since I install the new openssl version system wide ./config --prefix=/usr zlib-dynamic --openssldir=/etc/ssl shared no-ssl2 Mario On 28 May 2015 at 21:45, Tom Browder wrote: > On Wed, May 27, 2015 at 1:09 PM, Andy Wang wrote: >> On 05/27/2015 11:33 AM, Mario Brandt wrote: > ... >>> mario@sasuke:~$ readelf -s /usr/lib/libssl.so | grep "SSL_CONF_CTX_finish" >>> 532: 000536f0 6 FUNCGLOBAL DEFAULT 11 >>> SSL_CONF_CTX_finish >>> 327: 000536f0 6 FUNCGLOBAL DEFAULT 11 >>> SSL_CONF_CTX_finish >>> >> That's interesting. I believe those methods are new to 1.0.2 >> and AFAIK neither debian 7 nor 8 ship with openssl 1.0.2 >> >> Either way, there was clearly a symbol mismatch. I build Apache 2.4 with >> openssl 1.0.2 (i also build this) and have no problems. >> >> The key is, I make a self-contained structure, so you need be sure to use >> the proper LD_LIBRARY_PATH to allow, at runtime, things to be able to find >> the right openssl libraries. >> >> For example, my shell script that builds pcre, openldap, openssl, and apache >> sets this: >> >> LD_LIBRARY_PATH=$APACHE_ROOT/lib:$OPENSSL_ROOT/lib:$OPENLDAP_ROOT/lib:$PCRE_ROOT/lib >> export LD_LIBRARY_PATH >> >> And I build in the following order: >> pcre >> openssl >> openldap >> httpd >> >> and have no problems. > > Mario, did that solve your problem? > > If not, I'll send my solution. > > Best, > > -Tom
Re: httpd and OpenSSL 1.0.2
On Wed, May 27, 2015 at 1:09 PM, Andy Wang wrote: > On 05/27/2015 11:33 AM, Mario Brandt wrote: ... >> mario@sasuke:~$ readelf -s /usr/lib/libssl.so | grep "SSL_CONF_CTX_finish" >> 532: 000536f0 6 FUNCGLOBAL DEFAULT 11 >> SSL_CONF_CTX_finish >> 327: 000536f0 6 FUNCGLOBAL DEFAULT 11 >> SSL_CONF_CTX_finish >> > That's interesting. I believe those methods are new to 1.0.2 > and AFAIK neither debian 7 nor 8 ship with openssl 1.0.2 > > Either way, there was clearly a symbol mismatch. I build Apache 2.4 with > openssl 1.0.2 (i also build this) and have no problems. > > The key is, I make a self-contained structure, so you need be sure to use > the proper LD_LIBRARY_PATH to allow, at runtime, things to be able to find > the right openssl libraries. > > For example, my shell script that builds pcre, openldap, openssl, and apache > sets this: > > LD_LIBRARY_PATH=$APACHE_ROOT/lib:$OPENSSL_ROOT/lib:$OPENLDAP_ROOT/lib:$PCRE_ROOT/lib > export LD_LIBRARY_PATH > > And I build in the following order: > pcre > openssl > openldap > httpd > > and have no problems. Mario, did that solve your problem? If not, I'll send my solution. Best, -Tom
Re: httpd and OpenSSL 1.0.2
On 05/27/2015 11:33 AM, Mario Brandt wrote: Hi Tom, I tried on Debian 7 and 8 both x64 To see your configure options would help a lot. The missing symbol is in the lib. mario@sasuke:~$ whereis libssl.so libssl: /usr/lib/libssl.a /usr/lib/libssl.so mario@sasuke:~$ readelf -s /usr/lib/libssl.so | grep "SSL_CONF_CTX_free" 531: 0005370034 FUNCGLOBAL DEFAULT 11 SSL_CONF_CTX_free 901: 0005370034 FUNCGLOBAL DEFAULT 11 SSL_CONF_CTX_free mario@sasuke:~$ readelf -s /usr/lib/libssl.so | grep "SSL_CONF_CTX_finish" 532: 000536f0 6 FUNCGLOBAL DEFAULT 11 SSL_CONF_CTX_finish 327: 000536f0 6 FUNCGLOBAL DEFAULT 11 SSL_CONF_CTX_finish Cheers Mario That's interesting. I believe those methods are new to 1.0.2 and AFAIK neither debian 7 nor 8 ship with openssl 1.0.2 https://packages.debian.org/search?searchon=sourcenames&keywords=openssl wheezy (7) ships with 1.0.1e with patches jessie (8) ships with 1.0.1k with patches so for your /usr/lib/libssl.so to contain those functions means you either compiled your own openssl and installed them into /usr/lib or pulled in a testing/unstable package. Either way, there was clearly a symbol mismatch. I build Apache 2.4 with openssl 1.0.2 (i also build this) and have no problems. The key is, I make a self-contained structure, so you need be sure to use the proper LD_LIBRARY_PATH to allow, at runtime, things to be able to find the right openssl libraries. For example, my shell script that builds pcre, openldap, openssl, and apache sets this: LD_LIBRARY_PATH=$APACHE_ROOT/lib:$OPENSSL_ROOT/lib:$OPENLDAP_ROOT/lib:$PCRE_ROOT/lib export LD_LIBRARY_PATH And I build in the following order: pcre openssl openldap httpd and have no problems. Andy
Re: httpd and OpenSSL 1.0.2
Hi Tom, I tried on Debian 7 and 8 both x64 To see your configure options would help a lot. The missing symbol is in the lib. mario@sasuke:~$ whereis libssl.so libssl: /usr/lib/libssl.a /usr/lib/libssl.so mario@sasuke:~$ readelf -s /usr/lib/libssl.so | grep "SSL_CONF_CTX_free" 531: 0005370034 FUNCGLOBAL DEFAULT 11 SSL_CONF_CTX_free 901: 0005370034 FUNCGLOBAL DEFAULT 11 SSL_CONF_CTX_free mario@sasuke:~$ readelf -s /usr/lib/libssl.so | grep "SSL_CONF_CTX_finish" 532: 000536f0 6 FUNCGLOBAL DEFAULT 11 SSL_CONF_CTX_finish 327: 000536f0 6 FUNCGLOBAL DEFAULT 11 SSL_CONF_CTX_finish Cheers Mario On 27 May 2015 at 15:29, Tom Browder wrote: > Mario, I did get it working, but I did have a bit more effort to make > the latest openssl work. Taking a quick look at your blog I believe I > can help, but I'll explain my solution in a follow-up message so this > thread is on the public mailing lists. > > I feel I must explain that I'm using a Debian 7, 64-bit server. It > might help if we could know your server info as other architectures > may require more or other tweaks. > > Finally, the best I can probably do is show you my configure options > which may conflict with yours. > > TO BE CONTINUED > > Best regards, > > -Tom
Re: httpd and OpenSSL 1.0.2
On May 27, 2015 5:26 AM, "Mario Brandt" wrote: > Hi Tom, > I saw you on the httpd dev mailing list about that topic. How did you > manage to build apache against 1.0.2? > > Cause if I try that I get in my VM > > /opt/apache2/modules/mod_ssl.so: undefined symbol: SSL_CONF_CTX_finish > > or on my real server > > /opt/apache2/modules/mod_ssl.so: undefined symbol: SSL_CONF_CTX_free > > OpenSSL > ./config --prefix=/usr zlib-dynamic --openssldir=/etc/ssl shared no-ssl2 > make depend > make > sudo make install > > > apache > ./configure --prefix=/opt/apache2 --enable-pie > --enable-mods-shared=all --enable-so --disable-include --enable-lua > --enable-deflate --enable-headers --enable-expires --enable-ssl=shared > --enable-mpms-shared=all --with-mpm=event --enable-rewrite > --with-z=$HOME/apache24/httpd-2.4.12/srclib/zlib --enable-module=ssl > --enable-fcgid --with-included-apr > --with-openssl=$HOME/apache24/openssl-1.0.2a > --enable-ssl-staticlib-deps > > with the 1.0.1m it works all fine > seehttps://github.com/JBlond/debian_build_apache24/blob/master/build_apache.sh > > > Please tell me how you got it working. Mario, I did get it working, but I did have a bit more effort to make the latest openssl work. Taking a quick look at your blog I believe I can help, but I'll explain my solution in a follow-up message so this thread is on the public mailing lists. I feel I must explain that I'm using a Debian 7, 64-bit server. It might help if we could know your server info as other architectures may require more or other tweaks. Finally, the best I can probably do is show you my configure options which may conflict with yours. TO BE CONTINUED Best regards, -Tom