Ресурсы: техническое описание TLS, LaTeX - в картинки (img), криптографическая библиотека Arduino, шифр "Кузнечик" на ассемблере AMD64/AVX и ARM64
Техническое: обнаружение статуса TLS-сертификата
Кстати, что касается обнаружения отзыва серверных TLS-сертификатов. Ещё раз подчеркну – речь здесь об оконечных, о серверных TLS-сертификатах. С сертификатами УЦ – ситуация отличается. Итак, для оконечных сертификатов, сейчас, согласно требованиям CA/B-форума, есть три базовых способа публикации статуса сертификата и несколько вариантов их комбинирования:
1) публикация CRL;
2) OCSP-респондер;
3) ничего (то есть, нет точки публикации информации о статусе сертификата).
Итак, первый вариант, CRL: файлы CRL выкладываются на точку раздачи, доступную по HTTP, откуда их можно скачивать; URL указывается в составе сертификата (отдельное поле). В ряде случаев применяется различный “шардинг” и множественные URL. Например, Let’s Encrypt использует для одного и того же поколения сертификатов и промежуточного УЦ большое количество разных имён CRL (они именованы порядковым номером: 1, 2, 3, …, 128). В сертификате может быть указано несколько точек раздачи CRL, с разными URL. Это важный аспект.
Второй вариант, OCSP: OCSP давно перевели в разряд опциональных, но данный протокол всё равно используется; и если используется, то публикуется точка доступа к OCSP-респондеру (на практике, транспортом тоже будет HTTP), URL указывается в сертификате (отдельное поле, отличается от поля для CRL). Может быть несколько URL OCSP.
Третий вариант, самый интересный: в сертификате вовсе не указано способа получения информации о статусе. Такое уже довольно давно допускается, но только для “короткоживущих” (short-lived) сертификатов. Сейчас, “короткоживущий” – это со сроком валидности не более семи суток (604,800 секунд). Поэтому, например, в шестидневных сертификатах Let’s Encrypt может вообще не быть ни CRL, ни OCSP. Ну, OCSP вы там точно не найдёте – в Let’s Encrypt давно перестали его предоставлять; а вот CRL – пока что найти можно, но заметьте, что это опционально.
Теперь, что касается комбинирования. В сертификате всё ещё может быть указан адрес OCSP-респондера, но не указан адрес CRL! То есть, встречаются корректные и валидные сертификаты, статус которых только по OCSP возможно определить, адреса точки раздачи CRL в них нет вовсе. Могут быть указаны и OCSP, и CRL. И может быть только CRL. То есть, если сертификат не “короткоживущий”, то CRL является обязательным, но только в том случае, если нет OCSP (который опционален).
В рамках определения статуса сертификата нужно аккуратно обрабатывать все варианты. Например, если в сертификате указано несколько точек раздачи CRL, то тот факт, что в CRL, полученном от одной из точек, серийного номера сертификата нет, не означает, что сертификат не отозван: его серийный номер может присутствовать в другом файле CRL. Проверять отсутствие нужно по всем CRL. Когда указан OCSP-респондер (или несколько), то нужно и его тоже проверить, если сертификат не нашёлся в CRL.
Адрес записки: https://dxdt.blog/2026/08/17/18936/
Похожие записки:
- Ретроспектива заметок: август 2010
- Переключение на ML-KEM в браузере Chrome
- Техническое: приложения, аутентификация и отпечатки ключей
- Сдвиги времени в сертификатах Let's Encrypt
- Mozilla Firefox и внедрение рекламных сообщений
- Выбор параметров криптосистем и NUMS
- Автоматизация ИИ-агентов и атаки
- Метаинформация, мессенджеры и цепочки событий в трафике
- Интернет-протокол "дымовой завесы"
- GNSS и управление трактором
- Полностью зашифрованные протоколы и DPI-блокирование
Новый
Написать комментарий