#Что означает проблема
При продлении сертификата достаточно изменить файл на диске не всегда: Apache должен загрузить его снова, нужный SSL-виртуальный хост должен ссылаться на актуальные файлы, а пользователь может подключаться к Nginx/CDN, который выдаёт собственный сертификат. Проверяйте сертификат именно по публичному доменному имени и с SNI; сравнение только даты файла на диске может ввести в заблуждение.
#Как различить причины
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| TLS завершает Nginx или CDNПубличный клиент вообще не общается с Apache по TLS. | В Apache свежий сертификат, но снаружи виден прежний. | Обновить сертификат на реальном входном узле. |
| Не тот VirtualHost или SNIНа одном IP несколько HTTPS-сайтов с разными сертификатами. | По одному домену сертификат новый, по другому — чужой/старый. | Проверить выбор VirtualHost, ServerName, SNI и IP. |
| Путь или перезагрузка не обновленыSSLCertificateFile продолжает ссылаться на старую цепочку либо Apache не перечитал файл. | Сертификат по пути отличается от публичного; служба не перезагружена. | Исправить путь после подтверждения пары ключ–сертификат и применить конфигурацию. |
#Подробная диагностика и устранение
- Проверьте выдаваемый сертификат с именем узлаНа своём компьютере откройте сайт по HTTPS и нажмите значок сведений о соединении → сведения о сертификате (названия зависят от браузера). Запишите Subject/имена SAN и срок действия. Для точной проверки в терминале используйте
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates -fingerprint -sha256, заменив домен. Вторая команда читает только открытый сертификат, приватный ключ не выводит. - Проверьте, на каком уровне работает TLSНайдите, кто принимает подключения на 443: Nginx, Apache, внешний балансировщик или CDN. Если TLS завершает Nginx/CDN, срок действия сертификата Apache может не влиять на публичное соединение. Посмотрите конфигурацию выбранного входного узла, а не копируйте сертификат сразу на все серверы. При многосерверной схеме проверьте каждый узел отдельно.
- Найдите SSL-виртуальный хост по доменуПодключитесь по SSH к Apache, выполните
sudo apache2ctl -S. Найдите домен в списке HTTPS-хостов и файл конфигурации. ПроверьтеServerName,ServerAlias,SSLCertificateFile,SSLCertificateKeyFileи, если применимо, настройки цепочки сертификатов. Наличие одного правильного VirtualHost не гарантирует, что IP:443 и SNI на самом деле попадают в него. - Сравните сертификат на диске с публичнымВыполните
sudo openssl x509 -in /фактический/путь/fullchain.pem -noout -subject -dates -fingerprint -sha256, заменив путь значением SSLCertificateFile из вашего VirtualHost. Сравните SHA-256 отпечаток с публичным выводом. Если они равны, а дата кажется старой, проверьте сам факт обновления сертификата у удостоверяющего центра. Если отличаются, найдите, какой узел и файл реально использует HTTPS. - Убедитесь, что ключ соответствует новому сертификатуПеред заменой сертификата проверьте соответствие пары сертификат–приватный ключ безопасным методом по публичным ключам в администраторской среде, не публикуя вывод закрытого ключа. Не пересылайте приватные ключи в переписке и не вставляйте их в общедоступный редактор. При ошибке пары Apache может не запуститься после reload; сначала подготовьте исправные файлы и резервную копию.
- Исправьте путь и цепочку без удаления прежней копииЕсли выбранный SSLCertificateFile ведёт к старому файлу, после резервного копирования замените его ссылкой на актуальный сертификат и корректную цепочку, используемую конкретным способом выпуска. Для Apache 2.4 сертификат с промежуточными удостоверяющими центрами обычно может быть размещён в одном PEM-файле. Не удаляйте старый ключ/сертификат до успешного применения и обратной проверки.
- Проверьте конфигурацию и перечитайте сертификатНа сервере выполните
sudo apache2ctl configtest. Только при Syntax OK выполнитеsudo systemctl reload apache2; если в вашей сборке смена ключа требует специального действия, следуйте регламенту хостинга и проверьте журнал. При ошибке загрузки сертификата/ключа верните прежние пути из резервной копии и проверьте конфигурацию заново. Не отключайте проверку TLS на клиентах. - Проверьте IPv4, IPv6 и несколько входных узловСнова проверьте публичный сертификат с правильным
-servername. Если ответы меняются между попытками, сравните A и AAAA домена, узлы балансировщика и CDN, которые могли остаться со старой версией. В браузере обновите соединение и проверьте дату; если публичный отпечаток всё ещё старый, не перезапускайте Apache многократно, ищите другой входной узел. - Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
#Как проверить результат
Сертификат снаружи относится к запрошенному домену, имеет актуальный срок действия и совпадает отпечатком с сертификатом на отвечающем TLS-узле; цепочка доверия проверяется без отключения защиты.
#Если проблема не устранена
Если после reload виден прежний сертификат, проверьте SNI, выбор IP:443, A/AAAA, Nginx/CDN и несколько балансируемых серверов. Не считайте обновление файлов на Apache доказательством изменения на внешнем узле.