Ошибка SSL-сертификата на сервере: диагностика цепочки и настройка nginx

Шаг первый: прочитать код ошибки

Браузер почти всегда называет причину — нужно только развернуть подробности и посмотреть на код. Не пытайтесь чинить сертификат, пока не знаете, какая именно проверка не прошла.

Отдельный маркер: ошибка видна только у одного пользователя, а у остальных сайт работает. Это почти наверняка не сервер — сбитое время на устройстве, антивирус с перехватом трафика или корпоративный прокси, подменяющий сертификаты.

Шаг второй: посмотреть, что сервер реально отдаёт

Панель хостинга и внешние чекеры показывают отфильтрованную картину. Правду говорит только прямое обращение к порту 443:

• Полный вывод рукопожатия с цепочкой: openssl s_client -connect example.ru:443 -servername example.ru -showcerts </dev/null. Обратите внимание на строку verify return code — код 0 (ok) означает, что цепочка собралась.
• Только даты и имена: echo | openssl s_client -connect example.ru:443 -servername example.ru 2>/dev/null | openssl x509 -noout -dates -subject -issuer.
• Проверка глазами клиента без браузерных послаблений: curl -Iv https://example.ru. Если curl ругается, а Chrome молчит — цепочка неполная.
• Сколько сертификатов в файле цепочки: openssl crl2pkcs7 -nocrl -certfile fullchain.pem | openssl pkcs7 -print_certs -noout. Для Let’s Encrypt их должно быть минимум два.

Параметр -servername обязателен: без него сервер не знает, какой сайт вы просите, и на машине с десятком доменов отдаст сертификат первого попавшегося. Половина ложных диагнозов рождается именно здесь.

Неполная цепочка: самая частая и самая коварная причина

Сертификат вашего сайта подписан не корневым центром напрямую, а промежуточным. Клиент должен построить путь от вашего сертификата до корня, которому доверяет система. Промежуточные сертификаты обязан прислать сервер — их нет ни в браузере, ни в операционной системе.

Коварство в том, что десктопный Chrome умеет самостоятельно догружать недостающее звено по ссылке внутри сертификата и маскирует проблему. А вот кто не умеет: Android-браузеры, мобильные приложения, curl и wget, серверы платёжных шлюзов, вебхуки CRM, парсеры поисковых систем. Классическая картина — «у меня всё открывается, но клиенты жалуются, а оплата не проходит».

Причина почти всегда одна: в конфиг подставлен файл только с сертификатом сайта. Правильно так:

• ssl_certificate /etc/letsencrypt/live/example.ru/fullchain.pem; — именно fullchain, а не cert.pem;
• ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;
• для платного сертификата — склеить в один файл ваш сертификат, а следом промежуточные из бандла поставщика, строго в этом порядке.

В cPanel и ISPmanager есть отдельное поле для цепочки (CA bundle) — если оно пустое, вы получите ровно эту ошибку.

Ошибки конфигурации nginx

Второй по частоте источник проблем — сам конфиг. Проверяйте по списку:

1. Забыли перезагрузить сервер. Файлы обновились, процесс держит старые в памяти. Лечится: sudo nginx -t && sudo systemctl reload nginx.
2. Домена нет ни в одном server_name. Запрос попадает в блок с default_server, и клиент получает сертификат чужого сайта — отсюда ERR_CERT_COMMON_NAME_INVALID.
3. Разные конфиги для www и без www. Один блок с сертификатом, второй — со старым или без. Проверяйте оба адреса отдельно.
4. Дублирующиеся блоки на 443 порту. nginx возьмёт первый подходящий, и это может быть не тот, который вы правили.
5. Ключ не соответствует сертификату — бывает после ручной замены файлов. Сверьте отпечатки: openssl x509 -noout -modulus -in cert.pem | openssl md5 и openssl rsa -noout -modulus -in privkey.pem | openssl md5 должны совпасть.
6. Права на файл ключа. nginx не стартует или падает в ошибку, если не может прочитать privkey.pem.
7. Устаревшие протоколы. Оставленные TLS 1.0 и 1.1 вызывают ошибки у современных клиентов и претензии сканеров безопасности: держите ssl_protocols TLSv1.2 TLSv1.3;.

Если сайт живёт в контейнере или за балансировщиком, добавьте ещё один слой проверки: сертификат мог обновиться на хосте, но приложение внутри контейнера продолжает держать старую копию до перезапуска. Мы такие вещи вылавливаем при сопровождении серверов — сценарий обновления должен явно перечитывать конфигурацию везде, где сертификат используется.

Когда проблема не на сервере

Прежде чем перекапывать конфиг, исключите внешние причины:

• Время на устройстве посетителя. Сбитая дата — мгновенная ошибка срока действия на всех сайтах сразу.
• Антивирус или корпоративный шлюз, который вскрывает трафик и подписывает страницы своим сертификатом. Проверяется в свойствах сертификата: там будет издатель вроде названия антивируса.
• Старая операционная система. Устройства с давно не обновлявшимися корневыми хранилищами не знают новых центров сертификации.
• Кеш браузера и HSTS. После починки сайт может продолжать ругаться в той же вкладке — проверяйте в режиме инкогнито или на другом устройстве.
• DNS указывает не туда. Домен ведёт на старый сервер, где сертификата нет, а вы правите новый.

Порядок починки и финальная проверка

Рабочая последовательность: определить код ошибки → посмотреть выдачу openssl s_client → сверить имена и даты → проверить количество сертификатов в цепочке → найти блок nginx, который реально обслуживает домен → исправить пути → nginx -t → reload → повторить проверку через curl и с телефона. После починки обязательно пройдите сценарий оплаты и отправку формы: именно интеграции страдают от цепочки первыми, и именно их поломку замечают позже всего. Если сайт после переезда на https ещё и просел в поиске, отдельно проверьте редиректы и канонические адреса — это уже вопрос поискового продвижения, а не сервера. Как правильно ставить сертификат с нуля, разобрано в других материалах раздела о безопасности сайтов.