AI API сообщает об ошибке SSL-сертификата: время системы, цепочка доверия и корпоративный прокси
Как отличить истёкший сертификат, несовпадение домена, отсутствие CA и корпоративную HTTPS-инспекцию, не отключая проверку TLS.
Ошибки certificate verify failed, unable to get local issuer certificate и ERR_TLS_CERT_ALTNAME_INVALID обычно относятся к проверке подлинности HTTPS-соединения. Смена модели, пополнение баланса или отключение проверки сертификата не устраняют причину.
Это руководство помогает собрать сведения без отправки API Key и переписки, а затем отличить проблему локального хранилища CA от корпоративного прокси или конфигурации провайдера. Оно не является тестом доступности конкретного посредника. Названия ошибок зависят от клиента и TLS-библиотеки.
1. Отличите проверку сертификата от отказа API
HTTPS-клиент проверяет, подходит ли сертификат имени сервера, действует ли он сейчас и строится ли цепочка до доверенного центра сертификации — CA. Сбой любого из этих этапов может прервать соединение.
| Сообщение или признак | Возможная причина | Первый шаг |
|---|---|---|
| certificate has expired / not yet valid | Истёкший или ещё не действующий сертификат, неверное время устройства | Проверить дату системы и срок действия |
| unable to get local issuer certificate | Неполная цепочка сервера или отсутствие нужного CA у клиента | Сравнить окружения и издателя сертификата |
| self-signed certificate in certificate chain | Корпоративная HTTPS-инспекция, частный CA или недоверенная цепочка | Уточнить у администратора, не доверять автоматически |
| ERR_TLS_CERT_ALTNAME_INVALID | Имя в URL не соответствует сертификату | Проверить домен API, не заменять его IP-адресом |
| JSON с HTTP 401/403 | Получен HTTP-ответ; проблема может быть в ключе или правах | Перейти к диагностике авторизации |
По названию ошибки нельзя определить виновную сторону. Например, недостающий издатель может означать как отсутствие промежуточного сертификата на сервере, так и устаревший пакет CA в контейнере. Если ваш backend принимает запрос, но не может подключиться к провайдеру, браузер иногда видит обёрнутую ошибку 500/502, а не исходное сообщение TLS.
2. Начните с проверки без ключа
Сначала проверьте дату, время и часовой пояс устройства, включите синхронизацию с доверенным источником. Не переводите дату назад ради сертификата с истёкшим сроком.
Затем сверьте имя API-сервера с подтверждённой официальной документацией. Сайт, кабинет и API могут находиться на разных доменах. Не используйте непроверенный «исправленный адрес» из чата. Проверьте опечатки, пробелы и случайную замену домена на IP.
Проверьте HTTPS именно в проблемном окружении, а не только в своём браузере. Используйте сетевую диагностику клиента или попросите разработчика выполнить запрос к известному безопасному диагностическому адресу без Authorization, Cookie, тела и секретных параметров URL. Проверка сертификата должна оставаться включённой; не следуйте автоматически на незнакомые домены.
Ответ 401, 404 или 405 от правильного API-хоста не доказывает работоспособность модели, но обычно показывает, что это соединение достигло уровня HTTP. При отказе проверки TLS HTTP-статуса может не быть вообще. Поэтому статус 200 — не единственный полезный результат такой проверки.
3. Сравните окружения
Запишите версию клиента, ОС, фактический хост API и полный код ошибки, но не ключ. Сравнивайте только разрешённые сети, меняя за один раз один фактор.
| Результат сравнения | На что обратить внимание |
|---|---|
| Браузер работает, программа на том же компьютере нет | Разные хранилища доверия, прокси и версии среды выполнения |
| Локально работает, контейнер не подключается | Время контейнера, пакет CA, runtime и исходящий прокси |
| Дома работает, в офисе нет | Корпоративная HTTPS-инспекция или правила сети; обратиться к администратору |
| Несколько независимых окружений показывают одинаковое несовпадение имени или истечение срока | Передать провайдеру сведения для проверки сертификата |
Это направления поиска, а не окончательные выводы. У браузера может быть другой кэш сертификатов и конфигурация доверия. Не обходите корпоративные ограничения ради сравнительного теста.
4. Действуйте в зависимости от причины
Хранилище CA компьютера или контейнера
Обновляйте пакет CA и поддерживаемую версию клиента через официальные каналы системы или runtime. В минимальном контейнерном образе может отсутствовать необходимая конфигурация CA; это нужно исправлять в сборке, а не скачиванием случайного набора корневых сертификатов.
Выбор хранилища curl зависит от сборки и TLS-библиотеки. Например, сборка с Schannel обычно использует хранилище Windows, а другие сборки могут читать файл сертификатов. Доверие в Windows не гарантирует ту же настройку во всех программах: важны конкретная версия и backend инструмента.
Корпоративный прокси или частный CA
Если администратор подтвердил HTTPS-инспекцию, получите CA по официальному каналу организации и отдельно проверьте отпечаток и назначение. Установка корневого CA расширяет доверие системы. Нельзя автоматически делать доверенным корнем сертификат, предложенный всплывающим окном сайта.
В Node.js переменная NODE_EXTRA_CA_CERTS может указывать на PEM-файл с дополнительными доверенными CA. Она читается при запуске процесса, поэтому после изменения нужно перезапустить сервис. Изменение переменной внутри уже запущенного процесса не обновляет его доверие. Если SDK явно задаёт параметр ca, поведение стандартного и дополнительного наборов CA отличается — проверьте настройки SDK. Это описание границ механизма, а не инструкция обычному пользователю самостоятельно устанавливать корпоративные сертификаты.
Домен, срок действия или цепочка провайдера
При несовпадении имени восстановите правильный хост из документации. Не пытайтесь исправить проблему подменой Host или отключением проверки имени. Если подтверждены истечение срока, неполная цепочка либо неправильная установка сертификата нового домена, исправление требуется на стороне провайдера. Добавление неизвестных CA не является надёжным решением.
Для важной задачи можно перейти к заранее проверенному независимому резервному сервису, а не доверять случайному «зеркалу». Перед переключением проверьте ID модели, формат API и правила обработки данных, а также возможные автоматические повторы исходного запроса.
5. Не оставляйте проверку отключённой
curl -k, verify=False в Python и NODE_TLS_REJECT_UNAUTHORIZED=0 в Node.js ослабляют или отключают проверку сертификата. Они не восстанавливают цепочку доверия, а лишают клиент важной проверки личности сервера. В результате ключ и содержимое запроса могут попасть не тому получателю.
Переход с HTTPS на HTTP также не является исправлением. Если старый пример предлагает постоянно использовать такие настройки, не переносите их в рабочую конфигурацию. Для диагностики в этом руководстве они не нужны.
Если проверка уже была отключена при передаче чувствительных данных, оцените риск по фактической сети и журналам. При вероятном доступе недоверенного получателя к ключу отзовите его, создайте новый и проверьте необычные вызовы. Одна ошибка сертификата сама по себе не доказывает утечку.
6. Проверьте исправление и подготовьте обращение
Проверьте переменные окружения, код и настройки SDK: обход проверки не должен оставаться включённым. Выполните HTTPS-проверку без ключа в том окружении, где возникала ошибка. После успеха используйте тестовый Key, доступную модель и короткий несекретный вопрос для полного вызова. Такой вызов может оплачиваться; используйте небольшой собственный тестовый бюджет.
Проверьте результат модели, журнал аккаунта и поведение после перезапуска. Успех только в браузере недостаточен. Если HTTPS уже работает, но веб-страница сообщает о межсайтовой ошибке, используйте руководство по CORS, не меняя доверие сертификатам снова. О хранении и отзыве ключей — в руководстве по безопасности API Key.
Поддержке передайте время и часовой пояс, имя API-хоста, версии ОС и клиента, исходный код ошибки, срок действия и издателя сертификата, наличие корпоративного прокси и результаты сравнения окружений. Перед отправкой скриншота скройте внутренние домены и другие закрытые сведения. Не отправляйте приватные ключи, Authorization, Cookie, полное тело запроса и необработанные отладочные журналы.
Источники, просмотренные 08.10.2026: curl: TLS Certificate Verification, Node.js: NODE_EXTRA_CA_CERTS. Работа прокси и хранилищ доверия зависит от версии и SDK: настройки одной среды нельзя автоматически переносить на все клиенты.