Bug 37823 - The openssl library linked is different between httpd and mod_ssl
Summary: The openssl library linked is different between httpd and mod_ssl
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: Build (show other bugs)
Version: 2.2.0
Hardware: All other
: P3 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: MassUpdate
Depends on:
Reported: 2005-12-07 20:44 UTC by Jun Futagawa
Modified: 2018-11-07 21:08 UTC (History)
0 users

the config.log produced by the build (63.84 KB, text/plain)
2005-12-08 03:56 UTC, Jun Futagawa
the output of "make clean > make.log ; make >> make.log" (243.18 KB, text/plain)
2005-12-08 04:10 UTC, Jun Futagawa

Note You need to log in before you can comment on or make changes to this bug.
Description Jun Futagawa 2005-12-07 20:44:52 UTC

I have just ccompiled 2.2.0. The openssl library linked is different between 
httpd and mod_ssl.

./configure \
--enable-mods-shared=all \

# ldd ./.libs/httpd
        libssl.so.4 => /lib/libssl.so.4 (0x003c0000)
        libcrypto.so.4 => /lib/libcrypto.so.4 (0x001e8000)
These libraries are included in the RPM package (0.9.7a, CentOS 4.2).

# ldd ./modules/ssl/.libs/mod_ssl.so
        libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00bb1000)
        libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00cdd000)
These libraries were installed by using the source code (0.9.8a).

# ServerToken
Server: Apache/2.2.0 (Unix) mod_ssl/2.2.0 OpenSSL/0.9.7a

This seems to be a problem in EXTRA_LIBS and SSL_LIBS.
I patched the configure file so that httpd and mod_ssl link same library.

# diff -urN configure.orig configure
--- configure.orig      2005-12-08 03:31:18.000000000 +0900
+++ configure   2005-12-08 03:31:47.000000000 +0900
@@ -20277,6 +20277,7 @@
   echo "  restoring LIBS to \"$LIBS\""
   echo "  setting EXTRA_LIBS to \"$EXTRA_LIBS\""

# ServerToken with pache
Server: Apache/2.2.0 (Unix) mod_ssl/2.2.0 OpenSSL/0.9.8a
Comment 1 Nick Kew 2005-12-07 23:46:52 UTC
marking as a build bug; leaving it to someone who groks autofoo to take any 
Comment 2 Joe Orton 2005-12-08 00:30:40 UTC
Can you attach the config.log produced by the build?
Comment 3 Joe Orton 2005-12-08 00:33:21 UTC
(and the entire output of "make clean; make", ideally - use the bugzilla
"attachment" feature!)
Comment 4 Jun Futagawa 2005-12-08 03:56:14 UTC
Created attachment 17176 [details]
the config.log produced by the build
Comment 5 Jun Futagawa 2005-12-08 04:10:05 UTC
Created attachment 17177 [details]
the output of "make clean > make.log ; make >> make.log"

mod_ssl use EXTRA_LIBS and SSL_LIBS(-lssl -lcrypto), but httpd use only
Comment 6 Joe Orton 2005-12-08 09:49:13 UTC
Did that patch actually make a difference?

httpd is not being linked directly against OpenSSL.  It is picking up a
dependency via one of the dependencies of libapr/libaprutil, I'd guess.  Output
of "ldd -v httpd" might be useful.  If you could attach the complete output of
the unpatched configure run too that might help.

Mix-and-matching versions of OpenSSL like this is really doomed to failure. 
Have you relinked the system OpenLDAP/Postresq/MySQL/etc.etc against 0.9.8a?
Comment 7 Jun Futagawa 2005-12-08 10:29:54 UTC
Yes, that patch make a difference in ServerToken information.
Before: Server: Apache/2.2.0 (Unix) mod_ssl/2.2.0 OpenSSL/0.9.7a
After:  Server: Apache/2.2.0 (Unix) mod_ssl/2.2.0 OpenSSL/0.9.8a

I understand that httpd is not being linked directly against OpenSSL.
However, ServerToken information actually depends on httpd linked against 
OpenSSL version, not mod_ssl.so.

When I installed by compiling the source code, OpenLDAP/MySQL and Apache 2.0.55 
(same configuration) linked against 0.9.8a.

[root httpd-2.0.55]# ldd ./.libs/httpd
        libz.so.1 => /usr/lib/libz.so.1 (0x00d56000)
*       libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x0044a000)
*       libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00332000)
        libaprutil-0.so.0 => not found
        libldap-2.2.so.7 => /usr/lib/libldap-2.2.so.7 (0x0012f000)
        liblber-2.2.so.7 => /usr/lib/liblber-2.2.so.7 (0x00162000)
        libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x00df5000)
        libdb-4.2.so => /lib/tls/i686/libdb-4.2.so (0x0016e000)
        libexpat.so.0 => /usr/lib/libexpat.so.0 (0x00db1000)
        libapr-0.so.0 => not found
        librt.so.1 => /lib/tls/librt.so.1 (0x00111000)
        libm.so.6 => /lib/tls/libm.so.6 (0x00d31000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x0023c000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x0026a000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00d68000)
        libdl.so.2 => /lib/libdl.so.2 (0x00d2b000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00bff000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x00d9c000)
        libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00280000)
        libssl.so.4 => /lib/libssl.so.4 (0x00294000)
        libcrypto.so.4 => /lib/libcrypto.so.4 (0x00482000)
        /lib/ld-linux.so.2 (0x00be6000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x002c8000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x0056b000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x00d7c000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x002dc000)

[root openldap-2.3.11]# ldd ./servers/slapd/slapd
        libdb-4.2.so => /lib/tls/i686/libdb-4.2.so (0x00c97000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00d9b000)
        libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0x00111000)
        libdl.so.2 => /lib/libdl.so.2 (0x00125000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x069af000)
*       libssl.so.0.9.8 => /usr/lib/libssl.so.0.9.8 (0x00580000)
*       libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00129000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x00de5000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00b6b000)
        /lib/ld-linux.so.2 (0x00b52000)
Comment 8 William A. Rowe Jr. 2018-11-07 21:08:17 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.