Сертификаты и центры сертификации

В прошлом уроке мы видели, что при TLS handshake сервер отправляет сертификат, и клиент его проверяет. Но что именно содержит сертификат? Как браузер знает, что сертификату можно доверять? Разберём инфраструктуру открытых ключей (PKI — Public Key Infrastructure) — систему, которая делает HTTPS возможным в масштабе интернета.

Что такое TLS-сертификат

TLS-сертификат — это цифровой документ, который связывает открытый ключ с конкретным доменом. Его структура определена стандартом X.509:

Сертификат X.509:
  Subject: CN=example.com          (кому выдан)
  Issuer: CN=R10, O=Let's Encrypt  (кто выдал)
  Valid from: 2026-04-01           (срок: начало)
  Valid to: 2026-06-30             (срок: конец, обычно 90 дней)
  Public Key: ...                  (открытый ключ сервера)
  Signature: ...                   (подпись Intermediate CA)
  SANs: example.com, *.example.com (DNS-имена)

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

Цепочка сертификатов (Certificate Chain)

Один сертификат не существует сам по себе — он часть цепочки доверия:

Root CA (корневой сертификат)
  └─ Intermediate CA (промежуточный сертификат)
       └─ Server Certificate (сертификат сайта)

Зачем три уровня? Root CA хранится в защищённом физическом хранилище (offline), его закрытый ключ никогда не используется напрямую для подписи сертификатов сайтов. Intermediate CA — это делегат: Root CA подписал сертификат Intermediate, а Intermediate уже подписывает сертификаты сайтов. Если Intermediate CA будет скомпрометирован, Root CA отзовёт его сертификат. Без промежуточного звена пришлось бы отзывать Root — а это катастрофа, так как все браузеры и ОС должны обновлять свой список корневых сертификатов.

Кто такие Root CA и почему им доверяют

Корневые сертификаты встроены в операционные системы и браузеры. Список доверенных Root CA ведётся программами:

Mozilla CA Certificate Program — для Firefox.
Apple Root Certificate Program — для Safari на macOS и iOS.
Google Chrome Root Program — для Chrome.
Microsoft Trusted Root Program — для Edge и Windows.

Чтобы стать Root CA, организация проходит аудит (например, WebTrust) и доказывает, что соблюдает строгие правила хранения ключей. Крупнейшие Root CA: Let's Encrypt (ISRG Root X1), DigiCert, Sectigo (бывший Comodo), AWS (Amazon Root CA), Google Trust Services. Всего в программе Mozilla около 150 доверенных корневых сертификатов.

Проверка отзыва: CRL и OCSP

Сертификат могут отозвать до истечения срока — например, если закрытый ключ сервера украли. Браузер должен проверить, не отозван ли сертификат. Два основных механизма:

CRL (Certificate Revocation List). CA публикует список отозванных сертификатов. Минус — список может быть большим (мегабайты), и браузер должен его скачивать.
OCSP (Online Certificate Status Protocol). Браузер отправляет серийный номер сертификата на OCSP-сервер CA и получает ответ: «valid» или «revoked». Быстрее CRL, но раскрывает CA, на какой сайт заходит пользователь. Решение — OCSP Stapling: сервер сам периодически получает OCSP-ответ и прикрепляет его к рукопожатию. Браузер проверяет ответ без обращения к CA.

Типы сертификатов: DV, OV, EV

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

Тип	Проверка	Что видит пользователь	Пример
DV (Domain Validation)	Владение доменом (через DNS/HTTP)	Просто замок	Let's Encrypt
OV (Organization Validation)	Домен + организация	Замок, в деталях — название организации	Коммерческие CA
EV (Extended Validation)	Строгая проверка юрлица	Раньше — зелёная плашка с названием компании	Банки, крупный бизнес

На практике 95% сайтов используют DV-сертификаты от Let's Encrypt. EV-сертификаты потеряли популярность: браузеры убрали зелёную плашку, так как пользователи всё равно не смотрели на неё. Разница в безопасности между DV и EV для шифрования нулевая — оба дают одинаковый уровень TLS.

Wildcard и SAN

Сертификат может покрывать несколько доменов:

SAN (Subject Alternative Names). Список конкретных доменов: example.com, www.example.com, api.example.com. До 100 имён в одном сертификате.
Wildcard. *.example.com покрывает все поддомены первого уровня: blog.example.com, api.example.com, но НЕ api.staging.example.com (второй уровень).

Для микросервисной архитектуры часто берут wildcard-сертификат, чтобы не управлять десятками отдельных сертификатов.

Как браузер решает, доверять ли сертификату

При получении сертификата браузер выполняет полный алгоритм проверки:

Signature check. Для каждого звена цепочки расшифровать подпись вышестоящим ключом и сравнить хэш.
Chain to trusted root. Пройти цепочку до верха — последний сертификат должен быть в доверенном хранилище ОС/браузера.
Name matching. Домен в URL должен совпадать с CN или одним из SAN в сертификате.
Validity period. notBefore ≤ текущее время ≤ notAfter.
Revocation check. OCSP/CRL подтверждает, что сертификат не отозван.
Certificate Transparency. Сертификат должен присутствовать в CT-логах (для новых сертификатов).

Если хоть один шаг не пройден — браузер прерывает соединение и показывает предупреждение. Частичной проверки не бывает.

Let's Encrypt и автоматизация

Let's Encrypt (запущен в 2016) кардинально изменил рынок сертификатов. До него:

Получение сертификата — платная услуга, ручная проверка, дни ожидания.
Обновление — ручное, раз в 1–2 года, легко забыть.

Let's Encrypt сделал процесс полностью автоматическим через протокол ACME (Automatic Certificate Management Environment):

# Установка Certbot
sudo apt install certbot

# Получение сертификата (Certbot автоматически докажет владение доменом)
sudo certbot --nginx -d example.com -d www.example.com

# Сертификат установлен и будет автоматически обновляться
# Certbot добавляет cron/systemd timer для автообновления

ACME-клиент (Certbot, acme.sh) доказывает владение доменом через DNS-запись или HTTP-файл, получает сертификат, настраивает веб-сервер и автоматически обновляет сертификат за 30 дней до истечения. Сертификаты Let's Encrypt живут 90 дней — короткий срок вынуждает автоматизировать обновление.

Certificate Transparency

Certificate Transparency (CT) — это система публичных логов, в которые CA обязаны записывать все выданные сертификаты. Браузеры проверяют, что сертификат присутствует в CT-логах. Цель: если CA скомпрометирован и выдал сертификат на google.com злоумышленнику, владелец домена может мониторить CT-логи и немедленно обнаружить проблему.

CT-логи публичны. Можно зайти на crt.sh и посмотреть все сертификаты, когда-либо выданные на любой домен.

Проверь себя

Зачем нужна цепочка сертификатов из трёх уровней, а не один?
Чем OCSP Stapling лучше обычного OCSP?
Что делает Certificate Transparency?

<details> <summary>Ответы</summary>

Root CA хранится offline для максимальной безопасности. Intermediate CA выполняет ежедневную работу по выдаче сертификатов. Компрометация Intermediate не требует замены Root, что значительно проще и быстрее.
При OCSP Stapling сервер сам прикрепляет свежий OCSP-ответ к рукопожатию. Браузер не обращается к CA напрямую — это быстрее и не раскрывает CA историю посещений пользователя.
Все выданные сертификаты записываются в публичные логи. Владельцы доменов могут мониторить логи и обнаруживать мошеннические сертификаты на свои домены.

</details>

Что унести с урока

TLS-сертификат (X.509) связывает открытый ключ с доменом через подпись центра сертификации.
Цепочка доверия: Root CA → Intermediate CA → Server Certificate. Root встроены в ОС и браузеры.
Отзыв проверяется через CRL или OCSP. OCSP Stapling — быстрее и приватнее.
Let's Encrypt + ACME автоматизировали выдачу и обновление сертификатов.

В завершающем уроке модуля разберём HSTS, Mixed Content и защитные механизмы HTTPS — что делают браузеры, чтобы защитить пользователей даже при ошибках конфигурации сайта.

Сертификаты и центры сертификации