apache 2.4.37 + mod_ssl built as DSO is not dynamcically linking the new openssl version

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

apache 2.4.37 + mod_ssl built as DSO is not dynamcically linking the new openssl version

jaiprakash j
Hi Folks,

I need Help in resolving this issue that I am facing.

I am using a centos7 build box that has openssl 1.0.1e-fips and I use configure command as follows:

  ./configure --prefix=$INSTALL_DIR \
            --enable-ssl \
            --enable-so \
            --enable-module=so\
            --enable-mods-shared=ssl\
            --enable-shared=ssl\

it "makes" everything fine and I can see mod_ssl.so in the $INSTALL_DIR but when I deploy this in a centos7 box that has openssl 1.0.2k-fips, I expect this new version to be picked up dynamically but it does not happen?

I see this loaded modules in which I can see ssl_module as shared as well(among others)

apachectl -M
Loaded Modules:
 core_module (static)
 so_module (static)
 http_module (static)
 mpm_event_module (static)
 ssl_module (shared)
 passenger_module (shared)
 apachehmsmodule_module (shared)

and I have my httpd.conf file having this line

LoadModule ssl_module modules/mod_ssl.so

ldd modules/mod_ssl.so

ldd httpd/modules/mod_ssl.so
        linux-vdso.so.1 =>  (0x00007ffeccfa5000)
        libssl.so.10 => /lib64/libssl.so.10 (0x00007f7973ecf000)
        libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f7973a6d000)

and it is pointing to a link

ls -lrt /lib64/libssl.so.10
lrwxrwxrwx 1 root root 16 Jan 31  2018 /lib64/libssl.so.10 -> libssl.so.1.0.2k

but if I run the query to this box using curl, it still picks up the built openssl version, why is this and how to troubleshoot to get the bottom of it?

curl --head 10.x.x.x:yyy
HTTP/1.1 400 Bad Request
Date: Wed, 08 May 2019 08:59:39 GMT
Server: Apache/2.4.37 (Unix) OpenSSL/1.0.1e-fips Phusion_Passenger/5.0.30
Content-Length: 362
Connection: close
Content-Type: text/html; charset=iso-8859-1

If I build the same with the new openssl version in the build machine that has new openssl version, then apache comes up fine in the test box with new version.

The idea here is to not compile and build the whole apache server config for every new openssl version that comes up for security reasons. 

Am I missing something while "making" please suggest.


Reply | Threaded
Open this post in threaded view
|

Re: apache 2.4.37 + mod_ssl built as DSO is not dynamcically linking the new openssl version

Daniel Ferradal
you are getting the version of openssl mod_ssl was compiled against.
There is nothing odd in there. Brtiefly, you are lucking you can use
mod_ssl with the version mismatch and/or may have issues in the long
run if you keep doing this.

El jue., 9 may. 2019 a las 3:52, jaiprakash j
(<[hidden email]>) escribió:

>
> Hi Folks,
>
> I need Help in resolving this issue that I am facing.
>
> I am using a centos7 build box that has openssl 1.0.1e-fips and I use configure command as follows:
>
>   ./configure --prefix=$INSTALL_DIR \
>             --enable-ssl \
>             --enable-so \
>             --enable-module=so\
>             --enable-mods-shared=ssl\
>             --enable-shared=ssl\
>
> it "makes" everything fine and I can see mod_ssl.so in the $INSTALL_DIR but when I deploy this in a centos7 box that has openssl 1.0.2k-fips, I expect this new version to be picked up dynamically but it does not happen?
>
> I see this loaded modules in which I can see ssl_module as shared as well(among others)
>
> apachectl -M
> Loaded Modules:
>  core_module (static)
>  so_module (static)
>  http_module (static)
>  mpm_event_module (static)
>  ssl_module (shared)
>  passenger_module (shared)
>  apachehmsmodule_module (shared)
>
> and I have my httpd.conf file having this line
>
> LoadModule ssl_module modules/mod_ssl.so
>
> ldd modules/mod_ssl.so
>
> ldd httpd/modules/mod_ssl.so
>         linux-vdso.so.1 =>  (0x00007ffeccfa5000)
>         libssl.so.10 => /lib64/libssl.so.10 (0x00007f7973ecf000)
>         libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f7973a6d000)
>
> and it is pointing to a link
>
> ls -lrt /lib64/libssl.so.10
> lrwxrwxrwx 1 root root 16 Jan 31  2018 /lib64/libssl.so.10 -> libssl.so.1.0.2k
>
> but if I run the query to this box using curl, it still picks up the built openssl version, why is this and how to troubleshoot to get the bottom of it?
>
> curl --head 10.x.x.x:yyy
> HTTP/1.1 400 Bad Request
> Date: Wed, 08 May 2019 08:59:39 GMT
> Server: Apache/2.4.37 (Unix) OpenSSL/1.0.1e-fips Phusion_Passenger/5.0.30
> Content-Length: 362
> Connection: close
> Content-Type: text/html; charset=iso-8859-1
>
> If I build the same with the new openssl version in the build machine that has new openssl version, then apache comes up fine in the test box with new version.
>
> The idea here is to not compile and build the whole apache server config for every new openssl version that comes up for security reasons.
>
> Am I missing something while "making" please suggest.
>
>


--
Daniel Ferradal
HTTPD Project
#httpd help at Freenode

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]