Apache, похоже, использует старый сертификат с истекшим сроком действия, хотя установлен новый


15

Apache 2.2.3 / mod_ssl / CentOS 5.5 VPS

Срок действия нашего сертификата истек 2011-10-06, и, несмотря на то, что мы, казалось бы, правильно установили новый, при переходе на сайт по-прежнему отображается сертификат с истекшим сроком действия! Я пытался удалить кеш браузера и использовать несколько разных браузеров. Соответствующие строки из файла ssl.conf (я исключил закомментированные.):

Listen 127.0.0.1:443
SSLSessionCache         shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout  300
# Note - I tried disabling SSLSessionCache with the "none" setting but it didn't help.
<VirtualHost 127.0.0.1:443>
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile /var/certs/gentlemanjoe.com/new2011/gentlemanjoe.com.crt
SSLCertificateKeyFile /var/certs/gentlemanjoe.com/new2011/gentlemanjoe.com.key
SSLCertificateChainFile /var/certs/gentlemanjoe.com/new2011/gd_bundle.crt
SetEnvIf User-Agent ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0
CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
ServerAdmin webmaster@donotemailme.com
DocumentRoot /var/www/gentlemanjoe.com
ServerName gentlemanjoe.com
<Directory /var/www/gentlemanjoe.com>
    AllowOverride All
    Order deny,allow
    allow from all
</Directory>          
</VirtualHost>

Вещи, которые я проверил

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

Затем я попытался убедиться, что меня не обманули, отредактировав неправильный файл конфигурации. Используя «locate», я нашел только один файл httpd.conf в /etc/httpd/conf/httpd.conf. Я также использовал «locate», чтобы убедиться, что существует только один файл ssl.conf, /etc/httpd/conf.d/ssl.conf. Ключевой файл - это то, что я сгенерировал, используя OpenSSL, следуя инструкциям, которые дал GoDaddy для генерации CSR.

Я подтвердил, что работаю с нужным сайтом, загрузив файл test.html в папку /var/www/gentlemanjoe.com и убедившись, что могу перейти на него. Но если я пытаюсь просмотреть тестовый файл в HTTPS, я получаю то же предупреждение об истечении срока действия сертификата.

Я проверил, что сам сертификат имеет правильную дату истечения срока действия:

openssl x509 -in /var/certs/gentlemanjoe.com/new2011/gentlemanjoe.com.crt -noout -text

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            07:e7:49:69:97:96:16
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., OU=http://certificates.godaddy.com/repository, CN=Go Daddy Secure Certification Authority/serialNumber=07969287
        Validity
            Not Before: Oct 21 17:37:55 2011 GMT
            Not After : Oct  8 21:16:03 2013 GMT
        Subject: C=CA, ST=BC, L=Burnaby, O=Diamond Bailey Consolidated Commercial Services Ltd, OU= , CN=www.gentlemanjoe.com

Я попытался повторно ввести сертификат в GoDaddy с новым CSR, и все, кажется, работает, но я получаю тот же результат в браузере.

Возможный ключ № 1

Всякий раз, когда я делаю «перезапуск apachectl», я вижу это в файле error_log:

[Fri Oct 21 18:03:33 2011] [notice] SIGHUP received.  Attempting to restart
[Fri Oct 21 18:03:33 2011] [notice] Digest: generating secret for digest authentication ...
[Fri Oct 21 18:03:33 2011] [notice] Digest: done
[Fri Oct 21 18:03:33 2011] [info] APR LDAP: Built with OpenLDAP LDAP SDK
[Fri Oct 21 18:03:33 2011] [info] LDAP: SSL support available
[Fri Oct 21 18:03:33 2011] [info] Init: Seeding PRNG with 256 bytes of entropy
[Fri Oct 21 18:03:33 2011] [info] Init: Generating temporary RSA private keys (512/1024 bits)
[Fri Oct 21 18:03:33 2011] [info] Init: Generating temporary DH parameters (512/1024 bits)
[Fri Oct 21 18:03:33 2011] [info] Shared memory session cache initialised
[Fri Oct 21 18:03:33 2011] [info] Init: Initializing (virtual) servers for SSL
[Fri Oct 21 18:03:33 2011] [warn] RSA server certificate CommonName (CN) `www.gentlemanjoe.com' does NOT match server name!?
[Fri Oct 21 18:03:33 2011] [info] Server: Apache/2.2.3, Interface: mod_ssl/2.2.3, Library: OpenSSL/0.9.8e-fips-rhel5
[Fri Oct 21 18:03:34 2011] [notice] Apache/2.2.3 (CentOS) configured -- resuming normal operations
[Fri Oct 21 18:03:34 2011] [info] Server built: Aug 30 2010 12:28:40

Специалисты GoDaddy говорят мне, что www против non-www не должен иметь значения, и я склонен согласиться, так как предупреждение безопасности в моем браузере не жалуется на несоответствие имени сервера, а скорее истекает , указывая, что старый сертификат все еще загружается как-то.

Возможный ключ № 2

Заголовок ответа HTTP-сервера для http://gentlemanjoe.com говорит «Андромеда», а не «Apache». Это кажется мне странным, поскольку мой поиск в Google «Андромеды» включает проект типа медиа-сервера, который не будет установлен на этом сервере (но я не могу сказать это с уверенностью, так как я не настроил ничего из этого , обычный администратор / разработчик в отпуске, и я просто помогаю другу с его сайтом.) Кроме того, файл httpd.conf не содержит строку «Андромеда», указывающую, что он не был изменен, чтобы выложить это. Так что это может быть платформа электронной коммерции Magento, которую он использует, но какой смысл заменять стандартный заголовок ответа Apache?


Что это за ошибка: Сертификат сервера RSA CommonName (CN) `www.gentlemanjoe.com 'НЕ соответствует имени сервера !?
Якорь ,

Я не совсем уверен, я думаю , что он жалуется, что www.gentlemanjoe.com не соответствует gentlemanjoe.com, но это не объясняет, почему сайт все еще использует сертификат с истекшим сроком действия. Если бы это была только распространенная ошибка несоответствия имени / имени сервера, разве я не увидел бы это в предупреждении безопасности браузера? Новый сертификат не должен отображаться как просроченный , но с другим предупреждением о несоответствии имени, верно?
Джордан Ригер

Ответы:


17

Что-то перед Apache. Проверьте этот конфиг:

Listen 127.0.0.1:443
....
<VirtualHost 127.0.0.1:443>

Он прослушивает только локальный хост, поэтому интернет-клиенты не обращаются к этой услуге напрямую - они, вероятно, получают прокси.

Для проверки работоспособности того, что Apache загружает правильный сертификат, подключите сервис непосредственно к слушателю Apache: openssl s_client -connect 127.0.0.1:443 -showcerts

Не уверен , что заголовок Андромеды, так что , давайте найдем этот процесс: lsof -i.

У Apache будет 127.0.0.1:443, в то время как у некоторой другой службы 0.0.0.0:443(или публичного адреса VPS :443) - это тот, который нуждается в новом сертификате.


Да! Спасибо, Шейн, это было очень логично. Мальчик это был тяжелый. Процесс оказался прокси-сервером nginx, который прослушивал IP-адрес, который я даже не знал, был связан с сервером, а затем передавал HTTPS и HTTP-запросы в Apache. Я понятия не имею, почему последний парень подумал, что это хорошая идея, это похоже на бессмысленную работу. И nginx потребовал, чтобы я переформатировал сертификаты, предоставленные GoDaddy, чтобы поместить сертификат сервера и цепочку полномочий в один файл в определенном порядке. В любом случае, это работает сейчас! Спасибо!
Джордан Ригер

2
@JordanRieger Рад слышать! Обычно nginx считается более легким и быстрым, чем Apache, поэтому может быть так, если он обрабатывает некоторые запросы внутри себя (скажем, статический контент) и передает только определенное подмножество запросов в Apache ... но похоже, что это просто отправляя все в Apache, так что вы правы - просто потеря производительности.
Шейн Мэдден

В нашем случае это был AWS ELB.
Акшай

0

Распространенным источником этой проблемы являются несколько запущенных экземпляров Apache. Изменения конфигурации фиксируются процессом, который вы (пере) запускаете, но запрос обслуживается старым процессом, который выполняется со старой конфигурацией.

Остановить службу:

service apache2 stop

Проверьте, доступен ли сайт. Если да, то вы определили причину.

Теперь беги

ps aux | grep apache

Это даст вам список запущенных процессов apache2 и их PID. Убейте их всех (обратите внимание, что эта команда также может возвращать несвязанные процессы с Apache по имени / имени пользователя и т. Д., Например, Apache Tomcat, возможно, вы не захотите их уничтожать.)

kill <pid>

Запустите ps aux еще раз и убедитесь, что процессы больше не работают.

Проверьте еще раз, если сайт доступен. Так не должно быть.

Теперь запустите сервис Apache

service apache2 start

Убедитесь, что новый сертификат обслуживается.

Если вы не хотите уничтожать процессы, вы можете перезагрузить систему. Это будет иметь тот же эффект.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.