Отзыв сертификатов: CRL, OCSP и короткоживущие сертификаты
Компоненты Netgap аутентифицируют друг друга по mTLS. Пока приватный ключ сервиса в безопасности, сертификат честно работает до даты Not After. Но если ключ утек — например, злоумышленник скопировал файлы со скомпрометированной машины — сертификат нужно аннулировать до истечения срока: подпись корня на нем по-прежнему математически верна, и без специального механизма все участники mTLS продолжат ему доверять. Для этого в PKI существуют механизмы отзыва — CRL и OCSP, — а также современная альтернатива для внутренней инфраструктуры: короткоживущие сертификаты. Базовая теория цепочки доверия — в статье Цепочка доверия, проверка статуса конкретного файла — в статье Инспекция и проверка.
1. Зачем нужен отзыв
Сертификат — это подписанное корнем утверждение «этому публичному ключу можно доверять до такой-то даты». Сам по себе он не знает, что приватный ключ уже украден. Типовые причины досрочного аннулирования:
- компрометация приватного ключа (утечка с сервера, попадание в репозиторий, кража ноутбука);
- вывод сервиса из эксплуатации — его сертификат больше не должен приниматься;
- ошибка выпуска: не тот
Subject/SAN, не те расширения (см. Выпуск сертификатов через OpenSSL); - компрометация промежуточного CA — отзыв целой ветки доверия.
2. CRL — Certificate Revocation List
CRL — это подписанный удостоверяющим центром файл-«черный список»: серийные номера всех отозванных, но еще не истекших сертификатов, с датой и причиной отзыва.
Минусы CRL:
- размер файла — если отозванных сертификатов много, список разрастается до мегабайт; скачивать и парсить его при проверках накладно;
- задержка обновления — CRL выпускается по расписанию (например, раз в сутки). Если ключ утек в 10:00, а следующее обновление в 23:00, весь день система принимает скомпрометированный сертификат.
3. OCSP — Online Certificate Status Protocol
OCSP решает проблему больших файлов: вместо скачивания всего списка проверяющая сторона делает точечный HTTP-запрос к специальному сервису — OCSP Responder.
- Клиент предъявляет сертификат с серийным номером, например
12345. - Проверяющая сторона отправляет запрос OCSP-ответчику: «каков статус сертификата 12345?».
- Ответчик отвечает:
Good(валиден),Revoked(отозван) илиUnknown(ему неизвестен). Ответ подписан ключом OCSP-сервера, подделать его нельзя.
Плюсы: ответы быстрые, трафик минимальный, статус актуален. Минус: каждое новое соединение порождает дополнительный сетевой запрос, а сам OCSP-ответчик становится точкой отказа. Отсюда два режима поведения при его недоступности:
| Режим | Поведение при недоступном OCSP | Риск |
|---|---|---|
| Hard Fail | Соединение отклоняется | Отказ в обслуживании легитимных клиентов при падении OCSP |
| Soft Fail | Соединение пропускается без проверки отзыва | Злоумышленник может заблокировать OCSP-трафик и пройти с отозванным сертификатом |
Soft Fail выбирают ради доступности, но фактически он превращает проверку отзыва в необязательную: атакующему достаточно сделать OCSP-ответчик недоступным для жертвы. Полагаться на Soft Fail как на меру безопасности нельзя.
4. OCSP Stapling
Компромисс, который чаще применяется при проверке серверов браузерами: сервер сам раз в несколько часов запрашивает у OCSP-ответчика подписанное, ограниченное по времени подтверждение «я не отозван» и прикрепляет («сшивает») его к своему сертификату прямо в handshake. Клиент получает свежий статус сразу и не ходит на сторонние серверы: ни лишней задержки, ни утечки информации о том, к кому подключается клиент.
5. Сравнение подходов
| Критерий | CRL | OCSP | OCSP Stapling | Короткоживущие сертификаты |
|---|---|---|---|---|
| Актуальность статуса | Часы/сутки (по расписанию) | Почти реальное время | Часы (срок годности staple) | Равна TTL сертификата (1–24 ч) |
| Нагрузка на проверяющего | Скачивание и парсинг всего списка | HTTP-запрос на каждое соединение | Нулевая (статус приходит в handshake) | Нулевая |
| Точка отказа | Хостинг CRL | OCSP-ответчик | OCSP-ответчик (но опрашивает сервер, заранее) | CA/центр выпуска (Vault и т. п.) |
| Приватность | Нормальная | OCSP-сервер видит, кто с кем соединяется | Нормальная | Нормальная |
| Сложность инфраструктуры | Низкая | Средняя | Средняя | Требуется автоматизация выпуска |
| Подходит для внутреннего mTLS | Ограниченно | Ограниченно | Редко | Рекомендуется |
6. Как зашить адреса CRL и OCSP в сертификат
Чтобы проверяющая сторона знала, где искать статус, URL-адреса CRL и OCSP записываются внутрь самого сертификата в момент его подписания. В файл расширений (например, client.ext, который используется при подписании — см. Выпуск сертификатов через OpenSSL) добавляются строки:
# URL, по которому публикуется файл со списком отзыва (CRL)
crlDistributionPoints = URI:http://pki.mycompany.local/crl.pem
# Адрес живого OCSP-ответчика для онлайн-проверки статуса
authorityInfoAccess = OCSP;URI:http://ocsp.mycompany.local
После подписания оба адреса видны в дампе сертификата (openssl x509 -text -noout) в блоках X509v3 CRL Distribution Points и Authority Information Access — проверить это можно командами из статьи Инспекция и проверка.
Записать URL в сертификат — полдела. CA обязан реально публиковать по этим адресам свежий CRL и держать работающий OCSP-ответчик, иначе клиенты будут вести себя согласно своему режиму Hard/Soft Fail.
7. Современный подход для внутреннего mTLS: короткоживущие сертификаты
Для внутренней инфраструктуры — а именно так устроен mTLS между компонентами Netgap — индустрия все чаще отказывается от CRL/OCSP в пользу короткоживущих сертификатов: TTL 1–24 часа с автоматической ротацией в фоне.
Логика проста: отзыв нужен, чтобы аннулировать сертификат до даты Not After. Если до Not After всегда остается не больше нескольких часов, «окно» жизни украденного ключа сжимается до тех же нескольких часов — при компрометации достаточно заблокировать сервису доступ к центру выпуска, и его сертификат сам «превратится в тыкву». Инфраструктура отзыва (публикация CRL, OCSP-ответчики, настройка Hard/Soft Fail на всех клиентах) при этом вообще не нужна.
Цена такого подхода — выпуск сертификатов обязан быть полностью автоматическим: вручную перевыпускать сертификаты каждые несколько часов невозможно. Как это организовать (HashiCorp Vault, cert-manager, Service Mesh) — в статье Автоматизация выпуска и ротация.
Какой бы механизм ни был выбран, главное — заранее определить сценарий реагирования на компрометацию ключа: кто, как и за какое время аннулирует сертификат, и проверять наличие адресов CRL/OCSP в выпущенных сертификатах дампом (Инспекция и проверка). Для компрометации промежуточного CA должен существовать план отзыва всей ветки доверия (Цепочка доверия).