Ошибка «не удалось проверить цепочку сертификатов»: как найти и устранить причину

Эта ошибка означает, что программа (браузер, почтовый клиент, скрипт, мобильное приложение) не смогла выстроить непрерывную цепочку доверия от сертификата вашего сайта до корневого сертификата, который уже есть в системе. В большинстве случаев проблема не в «сломанном интернете» и не в самом ключе, а в одном из четырёх мест: не установлен промежуточный сертификат, истёк или ещё не начал действовать срок, неверное системное время на устройстве клиента либо неполная/повреждённая цепочка в конфигурации сервера. Ниже — как быстро локализовать причину и что с ней делать.

Что такое цепочка сертификатов и почему она ломается

SSL/TLS-сертификат не проверяется сам по себе. Браузер строит путь: сертификат сайта → промежуточный сертификат удостоверяющего центра → корневой сертификат, зашитый в операционную систему или браузер. Если хотя бы одно звено отсутствует, просрочено или подписано не тем, кем заявлено, проверка завершается ошибкой.

Типичные причины сбоя:

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

Первый шаг: прочитать точный текст ошибки

Общая формулировка «не удалось проверить цепочку» малоинформативна. Почти всегда рядом есть код или уточнение, которое сразу указывает направление поиска:

Уточнение в сообщении	Наиболее вероятная причина	Куда смотреть
«unable to get local issuer certificate» / «издатель не найден»	Промежуточный сертификат не отдан сервером либо нет корня в хранилище	Конфигурация веб-сервера; состав цепочки
«certificate has expired» / «истёк»	Просрочен сертификат сайта или промежуточное звено	Срок действия всех звеньев
«not yet valid» / «ещё не действует»	Сертификат выпущен только что или сбиты часы	Дата начала действия; время на устройстве
«self-signed certificate»	Самоподписанный сертификат вместо сертификата от публичного центра	Тип сертификата; способ выпуска
«hostname mismatch» / имя не совпадает	Сертификат выдан другому домену, нет нужного SAN	Список доменов в сертификате
«revoked» / отозван	Центр отозвал сертификат или проверка отзыва недоступна	Статус отзыва; доступность OCSP/CRL

Если точного кода нет, откройте сайт в браузере и посмотрите детали предупреждения: там обычно указано конкретное звено, вызвавшее сомнение.

Как проверить цепочку со стороны клиента

Начните с простых действий, которые доступны любому пользователю и отсекают половину причин:

1. Проверьте системное время и часовой пояс. Расхождение даже в несколько часов ломает проверку сроков. Особенно часто это встречается после замены батарейки BIOS на старых ПК и на устройствах с разряженной батареей.
2. Обновите операционную систему и браузер. Устаревшие хранилища корневых сертификатов не знают о новых центрах сертификации.
3. Откройте проблемный сайт с другого устройства и другой сети (например, с телефона через мобильный интернет). Если ошибка только на одном устройстве — проблема локальная. Если везде — на стороне сервера.
4. В браузере откройте сведения о сертификате (значок замка → сертификат) и посмотрите вкладку пути сертификации: видно, сколько звеньев дошло до корня и где цепочка обрывается.

Если ошибка возникает в корпоративной сети, добавьте к списку проверку прокси-сервера и антивируса с функцией фильтрации HTTPS: они подменяют сертификаты собственными, и без установленного корпоративного корневого сертификата проверка закономерно падает.

Диагностика со стороны сервера

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

Через OpenSSL выполните запрос к порту 443 своего домена и изучите вывод: команда покажет список передаваемых сертификатов, их сроки и порядок. Цепочка должна идти от сертификата домена к промежуточным и заканчиваться корнем (сам корень передавать не обязательно, но промежуточные — обязательно).

Онлайн-проверщики SSL позволяют сделать то же самое в один клик: они показывают, полная ли цепочка, какие звенья отсутствуют, совпадает ли домен и действителен ли срок. Это самый быстрый способ получить наглядную картину без доступа к консоли.

Частые серверные причины и их устранение

• Не установлен промежуточный сертификат. При выпуске сертификата центр выдаёт файл(ы) промежуточных звеньев — их нужно добавить в конфигурацию сервера. В nginx для этого используется директива ssl_trusted_chain/файл полного bundle, в Apache — параметр SSLCertificateChainFile (в новых версиях цепочку можно объединить с основным файлом). Точные названия параметров зависят от версии сервера — сверяйтесь с документацией вашей версии.
• Неправильный порядок сертификатов в bundle. Сначала должен идти сертификат домена, затем промежуточные от ближнего к дальнему. Перепутанный порядок часть клиентов отвергает.
• Истёк промежуточный сертификат. Такое случается при ротации цепочек центрами: сайт работает годами, а потом внезапно «падает», хотя сертификат домена ещё действителен. Решение — обновить bundle из свежей выдачи центра.
• Используется старый файл сертификата после перевыпуска. Проверьте, что в конфигурации указаны именно новые файлы, и перезапустите сервер после изменения.

Особые сценарии

Почтовые клиенты и внутренние сервисы

Если ошибка появляется в почтовой программе при подключении по IMAP/SMTP или во внутренней системе, дело может быть в самоподписанном сертификате корпоративного сервера. Здесь два корректных пути: выпустить сертификат от публичного центра (для внешних доменов это стандарт) либо добавить корпоративный корневой сертификат в хранилище доверия на клиентах. Отключать проверку сертификата в настройках клиента допустимо только как временную меру диагностики — постоянное отключение лишает соединение защиты от перехвата.

Скрипты, CI/CD и библиотеки

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

Старые устройства и embedded-системы

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

Типичные ошибки при устранении

• Отключение проверки сертификатов («ignore SSL errors») вместо исправления цепочки. Проблема маскируется, но защита исчезает.
• Ручная установка чужих корневых сертификатов, найденных в интернете, «чтобы заработало». Это прямой путь к компрометации доверия системы.
• Перевыпуск сертификата, когда дело было в промежуточном звене или времени клиента, — трата денег и времени без результата.
• Правка конфигурации без перезагрузки/перезапуска сервиса — изменения не применяются, и кажется, что причина в другом.
• Игнорирование предупреждения в браузере на рабочем сайте: посетители уходят, а поисковые системы понижают доверие к ресурсу с невалидным HTTPS.

Порядок действий: краткий алгоритм

1. Зафиксируйте точный текст и код ошибки, устройство и сеть, где она возникает.
2. Проверьте время и дату на клиенте, обновите систему и браузер.
3. Повторите попытку с другого устройства и сети, чтобы разделить проблемы клиента и сервера.
4. Если ошибка массовая — проверьте цепочку онлайн-инструментом или через OpenSSL.
5. Устраните найденное: дополните цепочку промежуточными сертификатами, обновите истёкшее звено, исправьте порядок в bundle, перезапустите сервер.
6. Повторите проверку и убедитесь, что цепочка строится до корня без предупреждений.

Когда обращаться к специалисту

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

Главный принцип: ошибка цепочки почти всегда локализуема. Определите, у кого она возникает (один клиент или все), прочитайте точный код и проверьте три вещи — полноту цепочки на сервере, сроки всех звеньев и корректность времени на клиенте. В подавляющем большинстве случаев причина находится среди этих трёх пунктов, а следующий практический шаг — прогнать домен через онлайн-проверку SSL и посмотреть, какое именно звено отсутствует или просрочено.

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