Как устранить ошибку CERTIFICATE_VERIFY_FAILED при использовании HTTPS через прокси

Что означает ошибка CERTIFICATE_VERIFY_FAILED при использовании прокси

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

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

Как прокси влияет на проверку TLS?

Прокси с туннелированием через CONNECT

При использовании HTTP-прокси с поддержкой CONNECT прокси устанавливает туннель к целевому серверу. Если на прокси или другом промежуточном устройстве не выполняется инспекция HTTPS, TLS-сеанс устанавливается между приложением и целевым сервером; прокси не подменяет сертификат сайта.

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

Прокси с функцией инспекции HTTPS

В некоторых корпоративных сетях прокси настроен администраторами для проверки HTTPS-трафика. Устройство завершает TLS-соединение от приложения, а затем устанавливает отдельное TLS-соединение с целевым сервером.

В этом случае приложение получает сертификат, выпущенный инфраструктурой CA организации. Для успешной проверки приложение должно доверять CA, одобренному организацией, при этом сертификат по-прежнему должен соответствовать требованиям к доменному имени, сроку действия и цепочке доверия.

Соединение с самим прокси также использует TLS

Если приложение поддерживает подключение к прокси по HTTPS, могут существовать два уровня TLS: один для соединения с прокси и другой для соединения с целевым сервером. Для этих уровней могут использоваться разные настройки CA.

Поэтому необходимо изучить ошибку и определить, какой именно сертификат отклонён. Добавление CA для соединения с сайтом не обязательно устранит ошибку проверки сертификата самого прокси.

Изучите сообщение об ошибке, прежде чем менять настройки

CERTIFICATE_VERIFY_FAILED — это общее сообщение. Сопутствующее описание обычно помогает определить тип причины:

• Не удалось получить сертификат локального издателя: приложение не может построить цепочку доверия до доверенного CA; возможно, отсутствует корневой или промежуточный сертификат.
• Самоподписанный сертификат в цепочке сертификатов: цепочка содержит самоподписанный сертификат, для которого не установлено надлежащее доверие.
• Срок действия сертификата истёк: срок действия одного из сертификатов в цепочке закончился либо на клиентском устройстве установлено неверное время.
• Несовпадение имени хоста: запрошенное имя хоста не соответствует имени, указанному в сертификате.

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

Определение источника ошибки SSL при использовании прокси

Сравнение в одинаковых условиях выполнения

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

То, что сайт открывается в браузере, не доказывает наличие всех необходимых CA у приложения. Браузер, Python, Java и контейнер могут использовать разные хранилища доверенных сертификатов.

Проверка фактически полученного сертификата

Используйте разрешённый организацией инструмент диагностики TLS, чтобы просмотреть субъект, издателя, срок действия и цепочку сертификатов. В OpenSSL с поддержкой прокси CONNECT можно использовать команду вида openssl s_client -proxy proxy.example:8080 -connect service.example:443 -servername service.example -showcerts.

Это пример для HTTP-прокси с поддержкой CONNECT; возможности аутентификации на прокси зависят от инструмента. Отображение сертификатов само по себе не доказывает корректность соединения, поскольку диагностический инструмент может продолжить работу после сообщения об ошибке проверки.

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

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

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

Перед использованием проверьте следующее:

• Имя субъекта и издатель соответствуют документации организации.
• Срок действия не истёк, а назначение сертификата соответствует предполагаемому использованию.
• Сертификат обладает свойствами CA в соответствии с архитектурой инфраструктуры.
• Отпечаток сертификата проверен по независимому доверенному каналу.
• Файл имеет формат, поддерживаемый приложением, например PEM.

Распространять нужно только открытый сертификат; не запрашивайте и не копируйте закрытый ключ CA. Также не следует по умолчанию добавлять сертификат целевого сервера в хранилище CA вместо исправления цепочки доверия.

Настройка хранилища доверенных сертификатов для нужного приложения

Хранилище сертификатов операционной системы

Если политика организации требует, чтобы несколько приложений доверяли внутреннему CA, администраторы могут распространить CA через хранилище доверенных сертификатов операционной системы. В Linux процедура зависит от дистрибутива; в Windows и macOS необходимо правильно выбрать область действия: для отдельного пользователя или для всей системы.

Однако некоторые среды выполнения не используют это хранилище автоматически. После установки всё равно необходимо проверить, из какого источника приложение загружает CA.

Отдельный набор CA для приложения

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

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

Устранение ошибки CERTIFICATE_VERIFY_FAILED в Python

Приложение использует Requests

В Requests путь к набору CA можно указать с помощью параметра verify, например requests.get(url, proxies=proxy_config, verify='/app/certs/company-ca-bundle.pem'). Это позволяет задать источник доверия, сохранив проверку сертификатов.

Для указания набора также можно использовать переменную окружения REQUESTS_CA_BUNDLE. Необходимо убедиться, что процесс действительно получает эту переменную; окружение службы, фоновой задачи и сеанса терминала может различаться.

Если приложение использует собственную логику обработки запросов или настраиваемый Session, проверьте загрузку настроек окружения. Не следует считать, что переменная, заданная в операционной системе, автоматически используется любым участком кода.

Приложение использует ssl или другие библиотеки

При использовании стандартной библиотеки можно создать контекст с помощью ssl.create_default_context(), а затем добавить CA через load_verify_locations(cafile=...). Такой способ позволяет загрузить дополнительные CA в контекст, уже содержащий стандартные настройки проверки.

Некоторые библиотеки поддерживают SSL_CERT_FILE или SSL_CERT_DIR, однако поведение зависит от среды выполнения и способа инициализации TLS в библиотеке. Следует изучить соответствующую документацию, а не применять одну переменную ко всем приложениям Python.

Не следует напрямую изменять файл CA в каталоге установки библиотеки: изменения могут исчезнуть при обновлении, а их согласованность между средами сложно контролировать.

Особенности curl, Node.js и Java

• curl: параметр --cacert задаёт CA для TLS-соединения с целевым сервером. При использовании HTTPS-прокси параметр --proxy-cacert служит для проверки TLS-соединения с прокси, если сборка поддерживает эту возможность.
• Node.js: NODE_EXTRA_CA_CERTS позволяет добавить CA при запуске процесса. Параметр ca, переданный непосредственно для соединения, может изменить используемый источник CA.
• Java: необходимо проверить, какое хранилище доверенных сертификатов фактически использует JVM или приложение. Установка CA в операционной системе не гарантирует, что Java автоматически начнёт ему доверять.

Независимо от инструмента сохраняйте проверку имени хоста и цепочки сертификатов. Доверие к CA не делает действительным сертификат с неверным доменным именем.

Контейнеры и среды CI/CD требуют отдельной настройки

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

В CI/CD необходимо проверить путь к файлу, права на чтение, учётную запись запуска и переменные окружения именно того шага, на котором возникает ошибка. Наличие CA на этапе сборки образа не означает, что он сохранится в итоговом образе для запуска.

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

Проверка после исправления настроек

После обновления источника доверия повторите запрос в той же среде, где возникала ошибка. Результат должен подтверждать успешное подключение с включённой проверкой TLS, а не просто получение HTTP-ответа.

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

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

Заключение

Устранение ошибки CERTIFICATE_VERIFY_FAILED при использовании HTTPS через прокси следует начинать с определения нужного уровня TLS и причины сбоя проверки. Надёжное решение состоит в исправлении цепочки сертификатов, распространении одобренных CA и правильной настройке хранилища доверенных сертификатов приложения.

При чётком управлении источниками доверия и проверке результата в реальной среде приложение может работать через прокси без отказа от проверки подлинности конечной точки HTTPS-соединения.