проверка TLS-сертификата можно освоить на одном небольшом проекте, если сразу видеть вход, действие и результат. Ошибка CERTIFICATE_VERIFY_FAILED означает, что Python не смог построить доверенную цепочку до корневого центра, а не то, что HTTPS нужно отключить. Ниже вы соберёте работающий пример и проверите обычный и граничный сценарии.
Популярный совет verify=False скрывает ошибку и разрешает подмену сервера, поэтому учебный код начинает работать ценой потери защиты. Поэтому отделим настройку, входные данные, основное действие и проверку. В этой статье вы соберёте диагностический скрипт, который принимает путь к CA bundle, делает HTTPS-запрос и показывает отдельные ошибки файла, DNS, тайм-аута и сертификата. Проверка: запрос проходит с доверенным bundle, verify остаётся включён, а неверный путь завершается понятным сообщением до сети.
сохранить полный текст SSLError и адрес. Не расширяйте проект до первого успешного запуска.
файл имеет ожидаемый формат и отпечаток. Проверяйте значение, а не отсутствие ошибки.
После успеха добавьте проверку существования bundle и безопасный текст для пользователя. Так копирование станет практикой.
Как устроен учебный проект проверка TLS-сертификата
Приложение проверяет существование PEM-файла, создаёт SSLContext или передаёт ca_bundle_file SDK, затем выполняет запрос с обычной проверкой hostname. Держите ввод, логику и отображение раздельно: тогда каждый этап можно проверить отдельно.
| Этап | Действие | Проверяемый результат |
|---|---|---|
| Диагноз | сохранить полный текст SSLError и адрес | понятен этап проверки сертификата |
| Сертификат | скачать корневой PEM из официального источника | файл имеет ожидаемый формат и отпечаток |
| Настройка | передать путь через REQUESTS_CA_BUNDLE или SDK | verify остаётся true |
| Проверка | повторить запрос и тест с неверным hostname | защита не отключена |
Контрольные точки: диагноз, сертификат, настройка и проверка. Следующий шаг начинается после совпадения с ожидаемым результатом.

От входных данных до видимого результата. Сначала проверяется вход, затем действие и только потом интерфейс.
Собираем рабочий пример шаг за шагом
Материал сверялся с официальной документацией 2 ноября 2026 года. Сохраните официальный корневой сертификат в папке certs вне кода приложения и передайте путь через переменную окружения REQUESTS_CA_BUNDLE. Проверьте текущую папку через pwd или Get-Location. Вставьте пример целиком, выполните один раз, затем разбирайте по частям.
import os
from pathlib import Path
import requests
URL = "https://gigachat.devices.sberbank.ru/api/v1/models"
def checked_get(url: str) -> int:
bundle = Path(os.environ["REQUESTS_CA_BUNDLE"]).expanduser().resolve()
if not bundle.is_file():
raise FileNotFoundError(f"CA bundle не найден: {bundle}")
response = requests.get(url, verify=str(bundle), timeout=15)
return response.status_code
if __name__ == "__main__":
try:
print("HTTP status:", checked_get(URL))
except requests.exceptions.SSLError as error:
raise SystemExit(f"TLS не подтверждён: {error}") from error- Корректный bundle позволяет завершить TLS handshake, после чего сервер может вернуть обычный HTTP-статус авторизации.
- Неверный путь останавливается как FileNotFoundError, а не превращается в verify=False.
- Повторный запуск даёт тот же предсказуемый результат.
- Пустой ввод получает понятное сообщение вместо падения.
Главная функция принимает явный вход и возвращает результат, который можно проверить отдельно от интерфейса. Найдите в примере вход, проверку и место формирования результата.

Что отличает устойчивый проект от случайного запуска. Явные границы делают ошибку локальной и понятной.
Что происходит внутри и почему это работает
Клиент проверяет подписи цепочки, срок действия и совпадение hostname. Дополнительный корневой сертификат расширяет доверенное хранилище для конкретного центра, но не отменяет остальные проверки. Логику держите отдельно от вывода: функция получает аргумент и возвращает значение, а интерфейс показывает его. В GigaChat Python SDK используйте параметр ca_bundle_file или переменную GIGACHAT_CA_BUNDLE_FILE. verify_ssl_certs=False оставляйте только для осознанной локальной диагностики без секретов, не для production.
| Часть | За что отвечает | Что проверить |
|---|---|---|
| PEM bundle | содержит доверенный корневой сертификат | файл взят из официального источника |
| TLS client | строит цепочку и проверяет hostname | verify включён |
| Application | отличает TLS, сеть и HTTP-ошибку | сообщения не скрывают причину |
Корневой сертификат не является клиентским секретом, но подменённый bundle может расширить доверие к злоумышленнику. Храните источник, отпечаток и процедуру обновления рядом с инфраструктурой. Не прячьте поток в одном обработчике: сохраните вход, проверьте его, вызовите операцию и только затем обновите интерфейс.
Проверяем проект и добавляем свою функцию
Сделайте функцию диагностики, которая печатает категорию ошибки, но не токен и не тело ответа. Добавьте тест для отсутствующего файла. До правки запишите ожидаемое поведение одним предложением. После граничного теста повторите обычный сценарий.
- Сохраните ожидаемый результат: запрос проходит с доверенным bundle, verify остаётся включён, а неверный путь завершается понятным сообщением до сети.
- Измените правило: добавьте проверку существования bundle и безопасный текст для пользователя. Сначала предскажите итог.
- Передайте граничное значение и убедитесь, что приложение не падает.
- Верните корректные данные и объясните роли трёх основных частей.
- понятен этап проверки сертификата
- файл имеет ожидаемый формат и отпечаток
- verify остаётся true
- защита не отключена
После изменения повторите основной и ошибочный сценарии, чтобы новое поведение не сломало исходный результат. Полезная правка проходит от нового ввода до видимого результата.

Четыре проверки перед следующим шагом. Каждый следующий этап начинается после наблюдаемого результата.
Что запомнить и куда двигаться дальше
После исправления удалите временные обходы, зафиксируйте путь через окружение и проверьте контейнер или CI, где системное хранилище может отличаться. Для закрепления откройте в подключении GigaChat API, в разборе CORS и в CI для Python.
Как изучить тему в Кодике
Сначала разберите формат входных данных и одну функцию, затем подключайте внешний сервис или интерфейс. Сначала восстановите главную функцию и проверьте её на трёх значениях.
| Шаг | Что разобрать | Мини-проверка |
|---|---|---|
| 1. Основа | Исключения, Path и переменные окружения Python | Объясните вход и выход функции. |
| 2. Инструмент | TLS-цепочку, корневой сертификат и hostname | Повторите команду по памяти. |
| 3. Проект | requests verify и ca_bundle_file SDK | Проверьте два сценария. |
| 4. Рефакторинг | Обновление сертификатов, контейнеры и безопасные логи | Разделите ввод, логику и вывод. |
Закрепите проект, восстановив ключевую функцию по памяти и добавив собственный граничный случай. Базовый синтаксис закрепите через курс Python.
Клиент больше не подтверждает сервер. Возможна атака посредника.
Вы не знаете, кому добавляете доверие. Берите официальный источник.
HTTP 401 означает, что защищённое соединение уже установлено.
Ошибка сертификата не требует печати Authorization. Скрывайте секреты.
Что получится в итоге

Финальный экран показывает результат, состояние операции и понятное сообщение об ошибке без раскрытия секретов.
Что именно отключает verify=False?
Проверку доверенной цепочки и hostname сервера.
Почему HTTP 401 лучше CERTIFICATE_VERIFY_FAILED для диагностики?
TLS уже успешно установлен, и проблема перешла на уровень авторизации.
Что проверять первым, если проверка TLS-сертификата не запускается?
Версию среды, текущую папку, команду запуска и первую строку ошибки.
Как понять, что проект проверка TLS-сертификата работает?
Проверьте основной сценарий, неверный ввод, повторный запуск и один граничный случай.
Можно ли начать с готового кода?
Да. Добейтесь результата, измените одно правило и восстановите ключевую функцию без копирования.
Выберите одно улучшение и проведите его от ввода до результата.
Если не хватает основы, перейдите курс Python, затем восстановите ключевую функцию без подсказки.