Здається, 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>

Те, що я перевірив

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

Тоді я спробував переконатися, що мене не обдурили, редагуючи неправильний файл конфігурації. Використовуючи "знайти", я знайшов лише один файл httpd.conf під /etc/httpd/conf/httpd.conf. Я також використав "Знайти", щоб переконатися, що існує лише один файл 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 vs non-www не має значення, і я схильний погоджуватися, оскільки попередження безпеки у моєму браузері не скаржиться на невідповідність імені сервера, а швидше закінчується термін дії , що вказує на те, що старий сертифікат все ще є завантажуючись якось.

Можливий ключ №2

Заголовок відповіді HTTP-сервера для http://gentlemanjoe.com говорить "Andromeda", а не "Apache". Мені це здається дивним, оскільки мій Googling з "Andromeda" виявляє проект типу медіа-сервера, який не був би встановлений на цьому сервері (але я не можу цього сказати з певністю, оскільки я нічого з цього не налаштував , звичайний адміністратор / розробник у відпустці, і я просто допомагаю другові зі своїм сайтом.) Також файл httpd.conf не містить рядка "Andromeda", що вказує на те, що він не був модифікований, щоб виплюнути це. Отже, це може бути платформа електронної комерції Magento, яку він використовує, але в чому сенс заміни стандартного заголовка відповіді Apache?


Що це за помилка: Сертифікат сервера RSA CommonName (CN) `www.gentlemanjoe.com 'НЕ відповідає імені сервера !?
mdpc

Я не дуже впевнений, я думаю, що скаржиться, що www.gentlemanjoe.com не відповідає gentlemanjoe.com, але це не пояснює, чому сайт все ще використовує сертифікат з минулим терміном дії. Якби це була лише помилка невідповідності імені / сервера, чи я б не бачив, що відображається в попередженні безпеки браузера? Новий сертифікат не повинен відображатися як закінчений , але з іншим попередженням про невідповідність імені, правда?
Йордан Рігер

Відповіді:


17

Щось перед Апачем. Перевірте цю конфігурацію:

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, щоб помістити сервер cert та ланцюжок повноважень в один файл у певному порядку. У будь-якому випадку це працює зараз! Дякую!
Йордан Рігер

2
@JordanRieger Приємно чути! nginx, як правило, вважається легшим і швидшим, ніж Apache, тому може виникнути випадок, якщо він обробляє деякі запити внутрішньо (скажімо, статичний вміст) і передає Apache лише певний підмножину запитів .. але це здається, що це просто надіславши все Apache, значить, ти маєш рацію - просто продуктивність.
Шейн Медден

У нашому випадку це був AWS ELB.
Акшай

1

Поширене джерело цієї проблеми - це кілька запущених екземплярів 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.