Эта ошибка особенно раздражает при работе с корпоративными прокси, самоподписанными сертификатами или устаревшими системами. Знание того, как её решить, сэкономит вам часы отладки и поможет правильно настроить безопасное соединение без компромиссов безопасности.

Почему вообще происходит эта ошибка

Когда приложение пытается подключиться к серверу через HTTPS, оно проверяет SSL/TLS сертификат сервера. Проверка — это не просто просмотр самого сертификата, а полная валидация цепочки доверия. Сертификат сервера обычно подписан промежуточным центром сертификации (intermediate CA), а тот, в свою очередь, подписан корневым центром (root CA).

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

• Устаревшее хранилище CA сертификатов — система давно не обновляла список доверенных центров, и новые корневые сертификаты просто не установлены
• Неправильный путь к CA bundle — приложение смотрит в неправильное место и не находит файл с сертификатами
• Корпоративный прокси или firewall — они блокируют или модифицируют SSL-соединение, требуя дополнительных сертификатов
• Самоподписанные сертификаты — в разработке часто используются сертификаты, которые никто не подписывал, и система их попросту не знает
• Неполная цепочка на сервере — сервер отправляет только сертификат, но не промежуточные сертификаты

Как исправить в разных языках и инструментах

Способ решения зависит от того, где именно вы столкнулись с ошибкой. Давайте разберём самые частые случаи.

Python и requests

Если вы используете библиотеку requests для HTTP запросов в Python, проблема обычно в том, что версия пакета certifi (который хранит список доверенных сертификатов) устаревшая. Первое, что нужно сделать — обновить его:

pip install --upgrade certifi

Это часто решает проблему, потому что certifi регулярно обновляется с новыми корневыми сертификатами. Если обновление не помогло, можно явно указать путь к CA bundle:

import ssl
import certifi

ssl_context = ssl.create_default_context(cafile=certifi.where())

Если у вас корпоративный сертификат, сохраните его в файл и используйте так:

import requests

response = requests.get(
    'https://your-domain.com',
    verify='/path/to/your-ca-bundle.pem'
)

Node.js

В Node.js ситуация похожа, но настраивается через переменную окружения. Установите переменную NODE_EXTRA_CA_CERTS, указав путь к вашему сертификату:

export NODE_EXTRA_CA_CERTS="/path/to/your-ca-bundle.pem"
node your-app.js

Она работает для всех Node.js приложений, запущенных в этой сессии терминала. Если нужно постоянно, добавьте это в .bashrc или .zshrc.

Для Azure DevOps или CI/CD пайплайнов переменная указывается в конфиге:

variables:
  NODE_EXTRA_CA_CERTS: $(Build.SourcesDirectory)/certs/my-root-ca.pem

cURL

cURL — это утилита, которая часто используется в скриптах и вебхуках. Если вы получаете ошибку при запросе, сначала обновите пакет ca-certificates:

# Для Debian/Ubuntu
sudo apt-get update
sudo apt-get install ca-certificates

# Для macOS
brew update
brew install curl-ca-bundle

Если это не поможет, укажите сертификат напрямую в команде:

curl --cacert /path/to/custom-ca.pem https://your-domain.com

Или укажите директорию с сертификатами:

curl --capath /etc/ssl/certs https://your-domain.com

Git

Git часто ругается на самоподписанные или внутренние сертификаты. Есть несколько подходов:

Обновить корневые сертификаты в системе. На Linux:

sudo update-ca-certificates

Если нужно быстро, но небезопасно, отключить проверку (только для разработки!):

git config --global http.sslVerify false

Боле правильный способ — добавить корпоративный сертификат в конфиг Git:

git config --global http.sslCAInfo /path/to/your-ca-bundle.pem

Postman

В Postman удобнее всего работать с настройками. Если у вас корпоративный сертификат:

1. Откройте Settings → Certificates → CA Certificates
2. Загрузите ваш CA bundle (полный сертификат с цепочкой)
3. Перезагрузите Postman
4. Включите проверку сертификатов в Settings → General → SSL certificate verification

Можно также отключить проверку в Settings → General, но это небезопасно для продакшена.

Таблица решений по ситуациям

Когда отключение проверки — это нормально

Это важный момент, потому что в интернете часто советуют просто отключить проверку сертификатов. Это работает, но… никогда не делайте это в продакшене. Это открывает двери для man-in-the-middle атак.

Отключение проверки допустимо только в очень специфических ситуациях:

• Локальная разработка с самоподписанными сертификатами
• Тестирование в контролируемой среде (вроде CI/CD для тестов)
• Временная отладка, когда вы точно знаете, что соединение безопасно

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

Практические советы, которые работают

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

# macOS
brew install curl-ca-bundle

# Ubuntu/Debian
sudo apt-get install ca-certificates
sudo update-ca-certificates

# Windows (PowerShell)
certutil -generateSSTFromWU roots.sst

Если это не помогло, найдите, где именно хранятся сертификаты в вашей системе. Для разных ОС это разные места:

• macOS: /usr/local/etc/openssl/cert.pem или через certifi.where() в Python
• Linux: /etc/ssl/certs/ca-certificates.crt или /etc/ssl/certs/
• Windows: Хранилище сертификатов системы (можно открыть через certlm.msc)

Проверьте, что ваше приложение смотрит в правильное место. Например, в Python:

import certifi
print(certifi.where())

Это покажет точный путь к CA bundle, который использует Python.

Если у вас есть корпоративный сертификат, убедитесь, что вы загружаете полную цепочку (root + intermediate + leaf), а не только один сертификат. Часто проблема именно в этом — забывают про промежуточный уровень.

На что стоит обратить внимание дальше

Эта ошибка часто указывает на более глубокие проблемы в настройке инфраструктуры. Если вы постоянно сталкиваетесь с ней, имеет смысл провести аудит SSL/TLS конфигурации на ваших серверах и в клиентских приложениях. Проверьте, что сервер правильно отправляет полную цепочку сертификатов, что все промежуточные CA включены, и что версии OpenSSL актуальны. Для глубокого анализа можно использовать онлайн-сервисы вроде SSL Labs. Также подумайте о том, имеет ли смысл вообще использовать самоподписанные сертификаты в разработке — может быть, проще настроить Let’s Encrypt для локальной сети или использовать инструменты вроде mkcert для генерации доверенных сертификатов на лету.