Слой 1. Кто кому доверяет
PKI — не один сертификат, а система ролей и локального доверия. Сначала определите издателя, делегированную регистрацию и точку, откуда проверяющий компонент получает исходное доверие.
PKI связывает конечные сущности, CA, необязательный RA, хранилища и отзыв. Сертификат открытого ключа связывает субъект с открытым ключом, но не хранит закрытый ключ и не выдаёт приложению права.
CA подписывает подтверждённую привязку и отвечает за состояние. RA может проверить регистрацию и передать решение, не получая ключ подписи CA.
Корневой CA обычно распространяется как якорь доверия, а промежуточный CA выполняет рабочий выпуск под ограничениями. Самоподпись корневого CA сама по себе не создаёт доверие.
Якорь доверия — настроенный вход проверки. Хранилище доверия — локальный набор якорей и правил, поэтому две среды выполнения могут вынести разные результаты проверки одной цепочки.
Слой 2. Что разрешает certificate
X.509 даёт структуру, профиль — допустимое содержание, а профиль приложения выбирает точную идентичность и назначение. Одно красивое поле не заменяет остальные проверки.
X.509 содержит издателя, субъект, срок действия, открытый ключ, подпись и расширения. Профиль сертификата ограничивает поля, алгоритмы, срок действия и расширения для конкретного класса.
subjectAltName хранит типизированные идентификаторы. Клиент TLS строит идентификатор проверки и сравнивает его с соответствующим SAN; запасной вариант commonName не используется.
Basic Constraints разрешает роль CA и ограничивает глубину. Key Usage задаёт криптографические операции, EKU — назначения для приложений; сертификат должен удовлетворять всем применимым ограничениям.
Name Constraints ограничивает пространства имён подчинённого CA на всём пути, но точная идентичность конечного сервиса всё равно проверяется отдельно.
Слой 3. От CSR до issuance
Запрос — ещё не разрешение. Издатель проверяет владение ключом, полномочия для точных идентификаторов и профиль, а ACME делает этот процесс машинно повторяемым.
PKCS #10 CSR содержит субъект, открытый ключ и запрошенные атрибуты и подписан закрытым ключом запроса. Подпись доказывает владение ключом, но не право на имя.
Выпуск сертификата связывает подтверждённую идентичность и точный ключ с разрешённым профилем; издатель не копирует расширения CSR вслепую.
ACME проводит учётную запись через заказ, проверку полномочий, испытание и финализацию CSR к ресурсу сертификата. Автоматизация протокола не отменяет политику CA.
Проверка полномочий хранит состояние связи учётной записи с идентификатором, а испытание — один способ доказать контроль. Все проверки полномочий и допустимый CSR нужны до выпуска.
Слой 4. Validate, rotate, revoke
После выпуска начинается эксплуатация: клиент должен построить путь, проверить его и идентичность сервиса, а платформа — заранее обновлять материалы и уметь досрочно отзывать их.
Цепочка сертификатов даёт возможную последовательность издателей. Построение пути ищет кандидата до локального якоря, а проверка пути проверяет подписи, время, ограничения и политику.
Продление получает новый сертификат до истечения срока действия. Ротация распространяет его, проверяет работающие конечные точки и только затем удаляет старые материалы.
Отзыв сообщает о досрочной недействительности. CRL публикует подписанный пакет, OCSP — статус каждого сертификата good, revoked или unknown; good не доказывает полную действительность.
mTLS проверяет сертификаты обеих сторон соединения, но сопоставление идентичности с ролью и авторизация конкретного действия остаются средствами управления приложения.
Проверьте инженерное мышление
Вопросы проверяют не память на аббревиатуры, а умение не делать лишних выводов.
Источники курса
Ссылки приведены один раз для всего курса, чтобы не мешать чтению каждого тезиса.
- Первичная спецификация
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile
Internet Engineering Task Force · RFC 5280, May 2008
Определяет Internet X.509 certificate и CRL profiles, PKI entities, extensions и certification path validation.
Открыть первоисточник - Первичная спецификация
Guidelines for API Protection for Cloud-Native Systems
National Institute of Standards and Technology · NIST SP 800-228-upd1, includes updates as of 13 March 2026
Задаёт API lifecycle controls для authentication, authorization, rate limits, resource limits, logging и monitoring.
Открыть первоисточник - Первичная спецификация
Recommendation for Key Management: Part 2 — Best Practices for Key Management Organizations
National Institute of Standards and Technology · NIST SP 800-57 Part 2 Rev. 1, March 2019
Описывает organizational key-management practices, CA/RA roles, PKI operations и certification path building.
Открыть первоисточник - Первичная спецификация
Service Identity in TLS
Internet Engineering Task Force · RFC 9525, November 2023
Задаёт construction и verification reference identifiers для TLS services; server identity находится в subjectAltName, не в commonName.
Открыть первоисточник - Первичная спецификация
PKCS #10: Certification Request Syntax Specification Version 1.7
Internet Engineering Task Force · RFC 2986, November 2000
Определяет структуру PKCS #10 CSR и подпись request information private key заявителя.
Открыть первоисточник - Первичная спецификация
Automatic Certificate Management Environment
Internet Engineering Task Force · RFC 8555, March 2019
Определяет ACME account, order, authorization, challenge, finalize, certificate download и revocation workflow.
Открыть первоисточник - Официальная документация
Recommendation for Key Management: Part 1 — General
National Institute of Standards and Technology · NIST SP 800-57 Part 1 Revision 5, May 2020
Определяет key-management functions, lifecycle states, cryptoperiods, protection, backup/recovery, compromise и destruction.
Открыть первоисточник - Первичная спецификация
X.509 Internet Public Key Infrastructure Online Certificate Status Protocol — OCSP
Internet Engineering Task Force · RFC 6960, June 2013
Определяет signed per-certificate status responses good, revoked и unknown и их validity interval.
Открыть первоисточник - Первичная спецификация
RFC 8446: The Transport Layer Security Protocol Version 1.3
Internet Engineering Task Force · RFC 8446, August 2018
Определяет TLS 1.3, включая encrypted channel, PSK authentication, PSK identity и PSK+(EC)DHE modes.
Открыть первоисточник