Сайт отдаёт неполную цепочку TLS-сертификатов после продления

#Что происходит и когда применима инструкция

Обновлённый серверный сертификат может быть действительным, но некоторым клиентам не хватает промежуточного сертификата для построения цепочки доверия. Проверьте, что веб-сервер передаёт leaf и требуемые промежуточные сертификаты из правильного fullchain, и отделите ошибку цепочки от неверного имени или устаревшего корневого хранилища клиента.

#Причины: как различить похожие случаи

#Диагностика и пошаговое устранение

1. 1. Зафиксируйте, у кого именно ошибкаОткройте сайт с разных браузеров или клиентских устройств. Если ошибка возникает лишь на некоторых старых устройствах, проверьте их доверенные корневые центры отдельно; если многие современные клиенты сообщают unable to get local issuer certificate, в первую очередь исследуйте цепочку сервера. Не советуйте нажимать «Всё равно перейти» и не отключайте проверку сертификатов.

1. 2. Посмотрите публичный набор сертификатовИз терминала с OpenSSL запросите сервер по имени, указав SNI. Параметр -showcerts выводит предъявленные сервером сертификаты, -servername нужен для правильного виртуального хоста. Сравните число и порядок PEM-блоков с ожидаемой цепочкой. Строка Verify return code полезна, но результат также зависит от локального набора доверенных корней.

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Заменить имя; сертификаты публичные, приватный ключ здесь не показывается.

   openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

1. 3. Определите, где реально завершается TLSПроверьте, проходит ли запрос через CDN, балансировщик, прокси или напрямую на Nginx/Apache. Если сертификат предъявляет CDN, локальная замена fullchain.pem не решит публичную проблему — настройте сертификат на внешней точке. При использовании Fastpanel/иной панели откройте карточку домена → HTTPS и посмотрите, какой сертификат привязан к хосту; не предполагайте, что файлы Certbot управляют панелью.

1. 4. Сравните публичный сертификат и файл на сервереЕсли сертификаты ведёт Certbot, проверьте certbot certificates, запишите Certificate Path. На Nginx по SSH найдите ssl_certificate и проверьте, что указан файл fullchain.pem, а не один cert.pem; privkey.pem нужен только для ssl_certificate_key и должен оставаться недоступным публике. Не переносите закрытый ключ в каталог сайта.

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Команды только читают данные, но вывод nginx -T может содержать конфиденциальные параметры.

   sudo certbot certificates

   sudo nginx -T

1. 5. Подготовьте правильную цепочку из штатного источникаПри выпуске Let’s Encrypt обычно используйте его управляемый live/.../fullchain.pem. Для другого удостоверяющего центра возьмите промежуточный сертификат из официального кабинета/хранилища этого центра и соберите цепочку в правильном порядке: сначала сертификат сервера, затем промежуточные. Не добавляйте произвольные корневые сертификаты и не делайте cat файлов с неподтверждённым происхождением.

1. 6. Сохраните конфиг и исправьте путь сертификатаПеред изменением сохраните копию блока Nginx server и исходные пути. Поменяйте ровно директиву ssl_certificate на проверенный полный комплект для этого имени; ssl_certificate_key должен соответствовать закрытому ключу сертификата. Если нет уверенности в соответствии пары — используйте проверку у администратора, не генерируйте новый закрытый ключ наугад. При управлении через панель применяйте изменение через интерфейс панели.

1. 7. Примените конфигурацию только после проверкиЗапустите sudo nginx -t: ожидается успешная проверка. При ошибке mismatch key/certificate ничего не перезагружайте; верните сохранённые пути или исправьте корректную пару. Только после успешного теста запустите sudo systemctl reload nginx. Обратите внимание, что тест проверяет конфигурацию, но не гарантирует правильности цепочки у внешнего CDN.

   Linux · Терминал (Bash)С осторожностьюНужен sudoКопировать всёВыделить

   Вторую строку выполнять лишь если первая завершилась успешно. Команда перезагрузки выполняется только при успешной проверке конфигурации (оператор &&). При ошибке исправьте конфигурацию и повторите проверку; не запускайте перезагрузку вручную.

   sudo nginx -t && sudo systemctl reload nginx

   Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

1. 8. Проверьте цепочку извне и автоматическое продлениеС другой машины повторите openssl s_client -showcerts и сравните промежуточные сертификаты. Проверяйте корневое имя и www отдельно, если они обслуживаются разными блоками. Убедитесь, что задача продления будет обновлять именно путь, используемый веб-сервером; если ошибка остаётся — приложите журнал Nginx и вывод публичной проверки без секретов.

#Как проверить, что неисправность устранена

Успех: современный браузер открывает HTTPS без предупреждения; OpenSSL видит корректную цепочку до доверенного центра, публичный leaf не просрочен и содержит нужное имя. Если ошибается только один старый клиент, диагностируйте его корневое хранилище отдельно.

#Если не получилось и как отменить правки

Верните прежнюю директиву ssl_certificate и путь ключа из сохранённого конфига, проверьте nginx -t и перезагрузите конфигурацию. Не удаляйте новый или старый сертификат до выяснения, какой из них используется автопродлением.

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