upgrade to apache 2.4.9 opensssl error SSL_get_srp_userinfo

Question

I am running Centos 6.5 2.6.32-431.11.2.el6.x86_64.

I have Apache PHP and openssl which I compiled from source

apache2.4.7 php 5.5.10 openssl 1.0.1f

I have updated apache to 2.4.7 on another instance sucessfully, but on this server I get the following error.

httpd: Syntax error on line 129 of /usr/local/apache2/conf/httpd.conf: Cannot load   modules/mod_ssl.so into server: /usr/local/apache2/modules/mod_ssl.so: undefined symbol: SSL_get_srp_userinfo

my config for the openssl is

./config --prefix=/usr/local --openssldir=/usr/local/openssl -fPIC

my config for apache, which is the config.nice for the previous 2.4.7 install is

"./configure" \
"--enable-so" \
"--with-included-apr" \
"--enable-ssl" \
"--with-ssl=/usr/local/openssl" \

I can see from the config.status that it is looking in the right place for the ssl

S["MOD_SSL_LDADD"]="-export-symbols-regex ssl_module"
S["ab_LDFLAGS"]="-L/usr/local/openssl/lib -lssl -lcrypto -lrt -lcrypt -lpthread"
S["ab_CFLAGS"]="-I/usr/local/openssl/include"

however when doing an ldd on the actual mod_ssl.so shows something totally different then what I see on all the other apache installation that I have working with mod_ssl.

normally on all the working installation I see something like

# ldd /usr/local/apache2/modules/mod_ssl.so
    linux-vdso.so.1 =>  (0x00007fff489ff000)
    librt.so.1 => /lib64/librt.so.1 (0x00007f839028d000)
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f8390056000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f838fe38000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f838faa5000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f83908bd000)
    libfreebl3.so => /lib64/libfreebl3.so (0x00007f838f843000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f838f63e000)[/CODE]

however, on this particular installation, i see

# ldd /usr/local/apache2/modules/mod_ssl.so
    linux-vdso.so.1 =>  (0x00007ffff1bff000)
    libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007f93f743b000)
    librt.so.1 => /lib64/librt.so.1 (0x00007f93f7232000)
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f93f6ffb000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f93f6dde000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f93f6a49000)
    libgssapi_krb5.so.2 => /lib64/libgssapi_krb5.so.2 (0x00007f93f6805000)
    libkrb5.so.3 => /lib64/libkrb5.so.3 (0x00007f93f651f000)
    libcom_err.so.2 => /lib64/libcom_err.so.2 (0x00007f93f631a000)
    libk5crypto.so.3 => /lib64/libk5crypto.so.3 (0x00007f93f60ee000)
    libcrypto.so.10 => /usr/lib64/libcrypto.so.10 (0x00007f93f5d0e000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f93f5b09000)
    libz.so.1 => /lib64/libz.so.1 (0x00007f93f58f3000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f93f7a7b000)
    libfreebl3.so => /lib64/libfreebl3.so (0x00007f93f567c000)
    libkrb5support.so.0 => /lib64/libkrb5support.so.0 (0x00007f93f5470000)
    libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x00007f93f526d000)
    libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f93f5053000)
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f93f4e33000)[/CODE]

this is a lot more extensive. I Do not think this could be because apache is not reading from the correct location for openssl.

Any suggestions are welcome.

thanks,

In order to PCI compliant, need to have the latest security patches. — user207044, Apr 07 '14 at 22:24
That doesn't necessarily mean you have to build everything from source. All of these packages are available in reliable repositories with full security updates. — Michael Hampton, Apr 07 '14 at 22:40

score 1 · Answer 1 · answered Apr 11 '14 at 09:57

1

Ok,

The solution was to put the actual LDFLAGS configuration in the actual configuration. so it should look like this

LDFLAGS="-L/usr/local/lib64"; export LDFLAGS
"./configure" \
"--enable-so" \
"--with-included-apr" \
"--enable-ssl" \
"--with-ssl=/usr/local/openssl" \
"LDFLAGS=-L/usr/local/lib64" \
"$@"

answered Apr 11 '14 at 09:57

user207044

11
1
2

After hours of banging my head against a brick wall, found this comment which was the solution for me - thanks! – Rob G Sep 14 '17 at 18:15

score 1 · Answer 2 · edited Apr 13 '17 at 12:14

I'm only adding this answer so that others who come by don't get misled by what you've tried to do, and the (very good) help that others have provided.

You are handling this completely the wrong way. You need to understand the way Red Hat, and therefore CentOS, deals with vulnerabilities and patching. You can read a fuller version here, but essentially: suppose EL6 (and therefore C6) ships with a package called foo, at version 1.1.1. When a vulnerability is found in foo-1.1.1, and the project releases 1.1.2, RH take the fix and backport it to version 1.1.1, releasing an RPM called (say) foo-1.1.1-2.

As long as you keep up with your patches, you are staying free of all the vulnerabilities that are known to affect foo 1.1.1, but foo --version will continue to report 1.1.1.

This is very hard for some security auditors to understand, particularly the ones who employ monkeys with version checklists. I cannot count the number of PCI audit reports I've had to rebut by going painfully through each so-called "vulnerability" they report, and by analysis of RH's changelogs, show that each CVE has already been addressed. (I personally regard PCI auditors who think that version checklists are the right way to check for vulnerabilities as professionally fraudulent, but that's a separate argument.) But for RH/CentOS systems, and others that follow the same patching scheme (which is most major distros), that is the right way to deal with these audits.

But worse than this, what you're doing actively harms security. For every package that you decide to update by hand, you now have to keep on top of it. You have to track each project separately, and each time they release a new version, you have to upgrade, destabilising your system and incurring downtime. Moreover, you have to do it as soon as it's released, not just at each audit, otherwise you'll be running a system that is actively insecure most of the time it's switched on.

Seriously: do not do the thing you are doing. It is the wrong thing. It is a dangerous thing. It is a hell of a lot of work for no actual advantage.

score 0 · Answer 3 · answered Jun 11 '14 at 21:38

I am running CentOS 6.5 2.6.32-431.17.1.el6.x86_64, mostly for supporting Java servlet containers

Thanks to your auto-answer, I've been able to build and get httpd running with SSL. The breakthrough for me was building both openssl and httpd with PIC/pie as appropriate

config arguments for OpenSSL 1.0.1h 5 Jun 2014 were used in this context

cd openssl-1.0.1h
./config -fPIC --prefix=/usr/local --openssldir=/usr/local/openssl
    make
    make test
    sudo make install

config for Apache/2.4.9 (Unix) APR 1.5.1, APR-UTIL 1.5.3 was this context

export LDFLAGS=”-L/usr/local/lib64”
./configure  --prefix=/usr/local/httpd \
   --enable-so \
   --enable-pie \
   --with-apr=/usr/local/apr/bin/apr-1-config \
   --enable-ssl \
   --with-ssl=/usr/local/openssl \
   --enable-allowmethods \
   --enable-info \
   --enable-speling \
   --with-mpm=prefork \
   LDFLAGS=-L/usr/local/lib64 \
   $@

And the changes that I made to httpd.conf before it worked were:

User apache
Group apache

LoadModule ssl_module modules/mod_ssl.so
LoadModule socache_shmcb_module modules/mod_socache_shmcb.so

Include conf/extra/httpd-ssl.conf

After which all that was necessary was to generate a self-signed cert and point to them appropriately in

conf/extra/httpd-ssl.conf

upgrade to apache 2.4.9 opensssl error SSL_get_srp_userinfo

3 Answers3