Ошибка сертификата, которая появляется после настройки прокси, может указывать на две совершенно разные вещи: либо присутствует промежуточный слой инспекции, либо это простая недоработка конфигурации. Различить их критически важно для вашей безопасности.
Что должно происходить в нормальной ситуации?
В корректно настроенном CONNECT-туннеле прокси вообще не касаетсясертификата. TLS-рукопожатие выполняется напрямую между клиентом и целевым сервером; прокси лишь передаёт зашифрованные байты. Следовательно, сертификат — это настоящий сертификат целевого сайта.
В таком сценарии появление ошибки сертификата не ожидается. Если ошибка есть, значит либо трафик перехватывается, либо хранилище сертификатов клиента неполное.
Причины ошибок
Вторая строка — тревожный признак: если в цепочке есть самоподписанный сертификат, ваш трафик, возможно, читают.
Как распознать SSL inspection?
Если значения issuer в двух выводах различаются, значит прокси выполняет перехват TLS и может читать ваш трафик.
Заглушить ошибку сертификата с помощью -k или verify=False не значит решить проблему — вы лишь делаете её невидимой. Это равносильно разрешению всем, кто находится посередине, читать ваш трафик. Никогда не используйте такой подход в продакшене.
Правильные решения
Обновите хранилище корневых сертификатов
Это самая частая причина. В Linux используйте update-ca-certificates, в Python — собственный коннектор с certifi обновите пакет.
Добавьте корпоративный корневой сертификат после проверки
Если вы в корпоративной сети и этого требует политика, добавьте в хранилище доверия вашего клиента корневой сертификат, полученный от ИТ-отдела. Никогда не добавляйте сертификат, скачанный из интернета.
Проверьте системное время
Неверное системное время делает действующие сертификаты «просроченными». Часто встречается на виртуальных машинах.
Используйте канал без перехвата TLS
Приложения с закреплением сертификата не принимают перехват. В этом случае потребуется мобильный интернет или прямое подключение.
Хранилище сертификатов на уровне приложения
Не каждое приложение использует системное хранилище доверия. Именно этим объясняется ситуация «в браузере работает, а в моём скрипте нет»:
| Среда | Хранилище сертификатов | Способ добавления |
|---|---|---|
| Системные утилиты Linux | /etc/ssl/certs | update-ca-certificates |
| Python (requests) | пакет certifi | REQUESTS_CA_BUNDLE переменная |
| Node.js | Встроенное хранилище | NODE_EXTRA_CA_CERTS переменная |
| Java | хранилище cacerts | keytool -import |
| Firefox | Собственное хранилище | Настройки → Сертификаты |
| Chrome | Системное хранилище | Настройка операционной системы |
Добавление сертификата на уровне всей системы делает его доверенным для всех приложений. Делайте это только для сертификатов, в источнике которых вы уверены.
Закрепление сертификата (Pinning)
Некоторые мобильные приложения и банковские клиенты закрепляют сертификат сервера внутри приложения. Увидев подставной сертификат, они отклоняют соединение — и никакое добавление корневого сертификата это поведение не изменит.
Именно этим объясняется жалоба «в корпоративном Wi-Fi приложение не открывается, а на мобильном интернете открывается». Единственное решение — использовать для этого приложения канал без перехвата TLS.
Резюме
В исправном CONNECT-туннеле прокси не касается сертификата; если вы видите ошибку, значит либо хранилище корневых сертификатов вашего клиента неполное, либо присутствует промежуточный слой инспекции. Чтобы различить эти две ситуации, сравните значение в цепочке сертификатов issuer с прямым подключением. Отключение проверки — не решение, а способ сделать риск невидимым. Чтобы увидеть, что на самом деле раскрывает ваше соединение, вы можете использовать тест анонимности наш инструмент.