обновите до апачских 2.4.9 opensssl ошибок SSL_get_srp_userinfo

Хорошо,

Решением было поместить фактическую конфигурацию 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, когда соответствующие аргументы конфигурации

для 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

для 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

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

Вы делаете это совершенно неправильно. Вы должны понимать, как 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 и других систем, которые следуют той же схеме исправления (которая является наиболее важной) distros), это правильный способ справиться с этими аудитами.

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

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