обновление до apache 2.4.9 ошибка opensssl SSL_get_srp_userinfo

Я добавляю этот ответ только для того, чтобы другие, кто приходит, не были введены в заблуждение тем, что вы пытались сделать, и (очень хорошей) помощью, которую оказали другие.

Вы делаете это совершенно неправильно. Вы должны понимать, как Red Hat и, следовательно, CentOS борются с уязвимостями и исправлениями. Вы можете прочитать более полную версию здесь, но по сути: предположим, что EL6 (и, следовательно, C6) поставляется с пакетом, называемым foo, в версии 1.1.1. Когда уязвимость обнаружена в foo-1.1.1, и проект выпускает 1.1.2, RH берет исправление и переносит его обратно в версию 1.1.1, выпуская RPM под названием (скажем) foo-1.1.1-2.

Пока вы следите за своими патчами, вы остаетесь свободными от всех известных уязвимостей, которые влияют на foo 1.1.1, но foo --version продолжу сообщать 1.1.1.

Некоторым аудиторам безопасности это очень трудно понять, особенно тем, кто нанимает обезьян с контрольными списками версий. Я не могу сосчитать количество отчетов аудита PCI, которые мне приходилось опровергать, мучительно просматривая каждый так называемый "уязвимость"они сообщают, и анализ журналов изменений RH показывает, что каждая ошибка CVE уже была рассмотрена. (Я лично считаю аудиторов PCI, которые считают, что контрольные списки версий являются правильным способом проверки уязвимостей, как профессионально мошеннические, но это отдельный аргумент). Но для систем RH / CentOS и других, которые следуют той же схеме установки исправлений (которая является большинством основных дистрибутивов), это правильный способ справиться с этими аудитами.

Но что еще хуже, то, что вы делаете активно вредит безопасность. Для каждого пакета, который вы решили обновить вручную, Теперь ты должен быть в курсе. Вы должны отслеживать каждый проект отдельно, и каждый раз, когда они выпускают новую версию, вы должны обновляться, дестабилизируя вашу систему и вызывая простои. Более того, вы должны делать это сразу после выпуска, а не только при каждом аудите, в противном случае вы будете запускать систему, которая большую часть времени активно небезопасна.

Шутки в сторону: не делай того, что делаешь. Это неправильно. Это опасно. Это чертовски много работы без реальной выгоды.

В порядке,

Решением было поместить фактическую конфигурацию LDFLAGS в фактическую конфигурацию. так это должно выглядеть так

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

Я использую CentOS 6.5 2.6.32-431.17.1.el6.x86_64, в основном для поддержки контейнеров сервлетов Java.

Благодаря вашему автоответу я смог создать и запустить httpd с SSL. Прорывом для меня было создание как openssl, так и httpd с PIC / pie в зависимости от ситуации.

В этом контексте использовались аргументы config для OpenSSL 1.0.1h 5 июня 2014 г.

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

config для Apache / 2.4.9 (Unix) APR 1.5.1, APR-UTIL 1.5.3 был этим контекстом

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

И изменения, которые я внес в httpd.conf до того, как он заработал, были:

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

После этого все, что было необходимо, - это создать самоподписанный сертификат и указать на них соответствующим образом в

conf / extra / httpd-ssl.conf