mise à niveau vers apache 2.4.9 opensssl error SSL_get_srp_userinfo

Je suis en train d'exécuter Centos 6.5 2.6.32-431.11.2.el6.x86_64.

J'ai Apache PHP et openssl que j'ai compilé à partir de la source

apache2.4.7 php 5.5.10 openssl 1.0.1f

J'ai mis à jour l'apache vers 2.4.7 sur une autre instance avec succès, mais sur ce server, j'ai l'erreur suivante.

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 

ma configuration pour openssl est

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

ma configuration pour apache, qui est le config.nice pour l'installation précédente 2.4.7 est

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

Je peux voir à partir du config.status qu'il regarde au bon endroit pour le 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" 

cependant, lorsque vous effectuez un ldd sur le mod_ssl.so réel, vous trouvez quelque chose de totalement différent, puis ce que je vois sur toutes les autres installations d'apache avec lesquelles j'ai travaillé avec mod_ssl.

normalement sur toute l'installation de travail, je vois quelque chose comme

 # 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] 

cependant, sur cette installation particulière, je vois

 # 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] 

C'est beaucoup plus vaste. Je ne pense pas que cela pourrait être parce que Apache ne lit pas de l'location correct pour openssl.

Toutes les suggestions sont les bienvenues.

Merci,

Je n'ajoute que cette réponse afin que les autres personnes qui se rendent ne soient pas induites en erreur par ce que vous avez essayé de faire, et les (très bonnes) aident les autres à en fournir.

Vous manipulez cela complètement dans le mauvais sens. Vous devez comprendre la façon dont Red Hat, et donc CentOS, se heurtent aux vulnérabilités et aux correctifs. Vous pouvez lire une version plus complète ici , mais essentiellement: supposons que EL6 (et donc C6) soit livré avec un package appelé foo , à la version 1.1.1. Lorsqu'une vulnérabilité est trouvée dans foo-1.1.1 , et le projet lance 1.1.2, RH prend la correction et la remonte à la version 1.1.1, libérant un RPM appelé (disons) foo-1.1.1-2 .

Tant que vous respectez vos correctifs, vous restz libre de toutes les vulnérabilités qui affectent foo 1.1.1, mais la version foo --version continuera à signaler 1.1.1 .

Il est très difficile pour certains auditeurs de security de comprendre, en particulier ceux qui emploient des singes avec des lists de contrôle de version. Je ne peux pas countr le nombre de rapports d'audit PCI que j'ai dû réfuter en faisant péniblement la « vulnérabilité » qu'ils signalent et, en analysant les agents de change de la SR, ils montrent que chaque CVE a déjà été abordé. (Je considère personnellement les auditeurs PCI qui pensent que les lists de vérification de la version sont le bon moyen de vérifier les vulnérabilités comme frauduleuses professionnelles, mais c'est un argument distinct.) Mais pour les systèmes RH / CentOS et d'autres qui suivent le même système de correctifs (ce qui est le plus important distros), c'est la bonne façon de traiter ces audits.

Mais pire que cela, ce que vous faites, cela nuit activement à la security. Pour chaque package que vous décidez de mettre à jour à la main, vous devez maintenant restr au courant . Vous devez suivre chaque projet séparément, et chaque fois qu'ils publient une nouvelle version, vous devez mettre à niveau, déstabiliser votre système et encourir des time d'arrêt. En outre, vous devez le faire dès qu'il est publié, pas seulement à chaque vérification, sinon vous allez exécuter un système qui est activement instable la plupart du time il est allumé.

Sérieusement: ne faites pas ce que vous faites . C'est la mauvaise chose. C'est dangereux. Il y a beaucoup de travail pour un avantage réel.

D'accord,

La solution était de mettre la configuration LDFLAGS réelle dans la configuration réelle. donc ça devrait ressembler à ça

 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" \ "$@" 

J'utilise CentOS 6.5 2.6.32-431.17.1.el6.x86_64, principalement pour la prise en charge des conteneurs de servlet Java

Grâce à votre réponse automatique, j'ai pu build et faire fonctionner httpd avec SSL. La percée pour moi a été de build à la fois openssl et httpd avec PIC / tarte, le cas échéant

les arguments de configuration pour OpenSSL 1.0.1h 5 juin 2014 ont été utilisés dans ce context

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

config pour Apache / 2.4.9 (Unix) APR 1.5.1, APR-UTIL 1.5.3 était ce 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 \ $@ 

Et les modifications que j'ai apscopes à httpd.conf avant cela ont été les suivantes:

 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 

Après quoi tout ce qui était nécessaire était de générer un cert auto-signé et de leur indiquer de manière appropriée dans

conf / extra / httpd-ssl.conf