Incomplete certificate chain: почему сайт открывается не у всех

Цепочка доверия состоит не только из вашего сертификата

Incomplete certificate chain означает, что сервер отдаёт не всю цепочку сертификатов, нужную клиенту для построения доверия. У сайта есть leaf-сертификат для домена, есть intermediate-сертификат центра сертификации и есть корневой сертификат, которому доверяет система. Обычно сервер должен отдавать leaf и intermediate, а корневой сертификат уже есть у клиента. Если intermediate отсутствует, часть устройств не сможет построить путь доверия.

Почему сайт открывается не у всех? Потому что клиенты отличаются. Один браузер может сам достать недостающий intermediate или иметь его в кэше. Другой клиент, старое устройство, корпоративная среда или библиотека внутри приложения может не сделать этого и показать ошибку. Владелец сайта видит нормальный доступ у себя и не понимает, почему жалобы выборочные.

Для общей темы сертификатов рядом полезен материал OCSP, цепочка сертификатов и ошибки SSL. Перед ремонтом chain стоит убедиться, что базовый SSL для домена выбран и установлен осознанно. Здесь фокус уже конкретный: неполная цепочка и её проверка на сервере.

fullchain отличается от одного cert.pem

В Let’s Encrypt и похожих схемах обычно есть файлы `cert.pem`, `chain.pem`, `fullchain.pem` и `privkey.pem`. Ошибка часто возникает, когда в конфигурации Nginx или Apache указывают только leaf-сертификат вместо fullchain. Сервер честно отдаёт сертификат домена, но не прикладывает промежуточный сертификат. Для части клиентов этого недостаточно.

В Nginx обычно нужно указывать `ssl_certificate` на fullchain, а `ssl_certificate_key` — на приватный ключ. Если после миграции пути меняли вручную, легко выбрать не тот файл. После renew тоже нужно убедиться, что веб-сервер читает актуальный fullchain, а не старый сертификат из резервной папки.

Ручная проверка из статьи как проверить SSL-сертификат сайта без лишних сервисов здесь особенно важна: браузер владельца может быть слишком «умным», а `openssl` покажет, какие сертификаты реально отдаёт сервер.

SNI и разные узлы могут отдавать разные цепочки

На одном проекте может быть несколько точек ответа: основной сервер, CDN, балансировщик, IPv4, IPv6, старый node, новый node. На одном узле fullchain подключён правильно, на другом — только leaf. Пользователь попадает на разные ответы и видит разные ошибки. Поэтому проверять нужно не только домен в целом, но и все публичные маршруты, которые могут обслуживать HTTPS.

SNI тоже влияет на картину. Если запрос пришёл без SNI или с другим именем, сервер может отдать default-сертификат с другой цепочкой. Это особенно заметно при мониторинге и старых клиентах. Ошибка «не у всех» иногда связана не с chain как файлом, а с тем, что разные клиенты получают разные сертификаты.

Если сертификат продлевается автоматически, цепочка может измениться при смене intermediate. Поэтому после обновления важно проверить внешний ответ, а не только дату файлов. Материал Certbot: как проверить сертификат и не пропустить сбой хорошо дополняет эту эксплуатационную часть.

Как проверить incomplete chain

Начните с `openssl s_client -connect domain:443 -servername domain -showcerts`. В выводе посмотрите, сколько сертификатов отдал сервер. Должен быть leaf и нужный intermediate. Затем проверьте verify return code. Если сервер отдаёт только один сертификат, а проверка цепочки не строится, вероятно, в конфигурации указан не fullchain.

После этого проверьте конфигурацию веб-сервера. В Nginx найдите `ssl_certificate` для нужного server block и убедитесь, что путь ведёт к fullchain. Выполните `nginx -t`, затем reload. После reload повторите внешний `openssl`. Если сайт за CDN, отдельно проверьте edge и origin, если origin доступен для диагностики. Если есть IPv6, проверьте и его: иногда A и AAAA ведут на разные узлы.

OCSP не заменяет цепочку. Даже хороший stapling не исправит отсутствие intermediate. Но после ремонта chain полезно проверить и статус отзыва. Для этого подходит статья OCSP: что это и почему проверка сертификата бывает неполной, потому что доверие состоит из нескольких связанных проверок.

Кейс: сайт работал на новых устройствах и падал на старых

Владелец перенёс сайт на новый сервер и указал в Nginx путь к `cert.pem`. На своём ноутбуке он видел зелёный замок. Часть пользователей со старых Android-устройств и один корпоративный клиент получали ошибку доверия. Сначала подозревали устаревшие браузеры, но `openssl -showcerts` показал, что сервер отдаёт только leaf-сертификат без intermediate.

После замены пути на `fullchain.pem`, проверки конфигурации и reload цепочка стала полной. Ошибка исчезла без перевыпуска сертификата. Вывод: incomplete certificate chain не всегда виден владельцу сайта. Надёжная проверка должна смотреть, что сервер отдаёт внешнему клиенту, а не только что лежит в папке с сертификатами.

Как разобрать неполную цепочку сертификатов

Где находится пропуск

Сертификат VPN сервера должен предъявлять полную цепочку, предусмотренную клиентом. Сайт VPN сервиса может иметь другую настройку. Домен для VPN сервера и адрес VPN сервера сверяют по профилю. Ошибка сертификата VPN на одном устройстве не всегда означает ошибку всех узлов.

Доверенные центры

Корневой сертификат VPN не устанавливают случайно на все устройства. Сертификат пользователя VPN относится к клиентской аутентификации, если она используется. SSL VPN проверяют по документации реализации. Сертификат для VPN должен соответствовать имени и политике доверия конкретного клиента.

Платформы

VPN для Android, VPN для iPhone и VPN для Windows могут по-разному находить промежуточные сертификаты. Профиль VPN сохраняют до правки. Если VPN не подключается только на одной платформе, сравните фактическую цепочку и системное время вместо отключения проверки.

Контроль

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

FAQ по incomplete certificate chain

Что такое intermediate certificate?

Это промежуточный сертификат между leaf-сертификатом сайта и корневым сертификатом CA. Именно он часто отсутствует при incomplete chain.

Почему fullchain нужен на сервере?

Потому что сервер должен отдать leaf и intermediate, чтобы клиент смог построить путь доверия до корня. Один `cert.pem` часто недостаточен.

Почему сайт открывается в одном браузере и ломается в другом?

Клиенты отличаются кэшем intermediate, хранилищем корней, поддержкой AIA fetching и TLS-библиотеками. Поэтому ошибка цепочки может быть выборочной.

Как проверить incomplete chain через openssl?

Используйте `openssl s_client -connect domain:443 -servername domain -showcerts` и смотрите, сколько сертификатов отдаёт сервер и какой verify return code получается.

Почему сертификат VPN работает на одном телефоне и не принимается на другом?

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

Почему сертификат для VPN работает на одном телефоне и отвергается на другом?

Различаться могут хранилище доверия, версия клиента и доступ к промежуточным сертификатам. Сверьте сертификат для VPN по имени и цепочке. Затем проверьте сертификат VPN в фактическом соединении, а не только файл на сервере.

Стоит ли вручную добавлять недостающий сертификат всем пользователям?

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