Расширения X.509v3
Расширения X.509v3 — это механизм, определённый в стандарте X.509 версии 3 (ITU-T и ISO/IEC), позволяющий включать в цифровые сертификаты открытых ключей дополнительную информацию, не предусмотренную базовыми полями сертификата. Расширения обеспечивают гибкость и функциональность инфраструктуры открытых ключей (PKI), позволяя задавать области применения сертификата, ограничения на пути сертификации, политики использования и метаданные, связанные с владельцем или удостоверяющим центром (УЦ).
История и стандартизация
Первоначально стандарт X.509 (1988 год) определял строго фиксированный набор полей для сертификатов: серийный номер, алгоритм подписи, имя эмитента, период действия, имя субъекта, открытый ключ и подпись УЦ. Однако с развитием PKI возникла потребность в добавлении контекстной информации — например, для указания, что сертификат предназначен только для проверки подписи электронной почты или для шифрования.
В 1996 году была опубликована версия 3 стандарта X.509 (X.509v3), в которой впервые был введён механизм расширений. Он был разработан для обеспечения совместимости: каждое расширение имеет уникальный идентификатор объекта (OID), а также флаг критичности (criticality). Если расширение помечено как критическое, приложение обязано его обработать; в противном случае его можно игнорировать. Позднее эта модель была принята в RFC 5280 (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile), который является основным стандартом для PKI в Интернете.
Структура расширения
Каждое расширение в сертификате X.509v3 состоит из трёх полей:
- extnID — OID, однозначно идентифицирующий тип расширения (например, 2.5.29.17 для Subject Alternative Name).
- critical — булево значение (TRUE или FALSE), указывающее, является ли расширение критическим. Если TRUE и приложение не распознаёт расширение, сертификат должен быть отклонён.
- extnValue — октетная строка (OCTET STRING), содержащая значение расширения в формате, определённом для данного OID.
Расширения могут быть стандартизированы (определены в RFC, ITU-T или IETF) или частными (private), используемыми в закрытых PKI. Стандартные расширения подразделяются на несколько категорий.
Классификация расширений
Расширения для ключей и базовых ограничений
Эти расширения определяют область применения открытого ключа и структуру PKI.
- Key Usage (использование ключа) — задаёт допустимые криптографические операции: цифровая подпись (digitalSignature), неотрекаемость (nonRepudiation), шифрование ключей (keyEncipherment), шифрование данных (dataEncipherment), согласование ключей (keyAgreement), подпись сертификатов (keyCertSign), подпись CRL (cRLSign), шифрование только ключа (encipherOnly) и только согласование (decipherOnly). Критическое расширение.
- Extended Key Usage (расширенное использование ключа) — уточняет цель использования сертификата на уровне приложений: например, серверная аутентификация (serverAuth), клиентская аутентификация (clientAuth), защищённая электронная почта (emailProtection), подпись кода (codeSigning). Некритическое по умолчанию, но может быть критическим.
- Basic Constraints (базовые ограничения) — указывает, является ли сертификат сертификатом УЦ (CA=TRUE) и задаёт максимальную длину цепочки сертификации (pathLenConstraint). Критическое расширение для сертификатов УЦ.
Расширения для имён и альтернативных идентификаторов
Позволяют связывать сертификат с дополнительными именами субъекта.
- Subject Alternative Name (SAN) — содержит альтернативные имена субъекта: DNS-имена, IP-адреса, адреса электронной почты, URI и другие. Широко используется в сертификатах TLS/SSL для указания доменов. Критическое в зависимости от контекста.
- Issuer Alternative Name — аналогично, но для эмитента сертификата.
- Subject Directory Attributes — атрибуты каталога (например, X.500), связанные с субъектом.
Расширения для политик и ограничений
Регулируют доверие и соответствие политикам PKI.
- Certificate Policies (политики сертификата) — содержит OID политик, которым соответствует сертификат, и опционально указатели на практические руководства (CPS). Некритическое.
- Policy Mappings (отображение политик) — используется только в сертификатах УЦ для отображения политик одного домена в другой. Критическое.
- Policy Constraints (ограничения политик) — запрещает или требует явного указания политик в цепочке сертификации. Критическое.
- Inhibit Any-Policy (запрет любой политики) — запрещает использование специального OID «anyPolicy» (2.5.29.32.0) в цепочке. Критическое.
Расширения для управления цепочками сертификации
Контролируют построение и проверку цепочек.
- Name Constraints (ограничения на имена) — задаёт разрешённые или запрещённые пространства имён (например, только домены *.example.com) для сертификатов, выпущенных данным УЦ. Критическое расширение.
- Authority Key Identifier (идентификатор ключа эмитента) — уникальный идентификатор открытого ключа УЦ, подписавшего сертификат. Некритическое.
- Subject Key Identifier (идентификатор ключа субъекта) — идентификатор открытого ключа субъекта. Некритическое, но рекомендуется для всех сертификатов.
Расширения для CRL и статуса сертификата
Используются в списках отзыва сертификатов (CRL) и протоколах проверки статуса.
- CRL Distribution Points (точки распространения CRL) — URI, указывающие, где можно получить CRL для данного сертификата. Некритическое.
- Freshest CRL (свежие CRL) — указывает на точки получения дельта-CRL (содержащих только изменения). Некритическое.
- Authority Information Access (AIA) — содержит URI для получения информации об эмитенте (например, OCSP-ответчика или сертификата УЦ). Некритическое.
Критические и некритические расширения
Флаг critical определяет строгость обработки расширения. Если расширение помечено как критическое (TRUE), то любое приложение, проверяющее сертификат, обязано распознать и корректно обработать это расширение. Если приложение не понимает критическое расширение, сертификат должен быть признан недействительным. Некритические расширения могут игнорироваться, если приложение не умеет их обрабатывать.
На практике большинство расширений, определяющих безопасность (Key Usage, Basic Constraints, Name Constraints), делаются критическими. Расширения для метаданных (SAN, AIA, CRL Distribution Points) обычно некритические, чтобы не нарушать совместимость с устаревшим ПО.
Применение
Расширения X.509v3 используются повсеместно в современных PKI:
- TLS/SSL-сертификаты — обязательное использование SAN для указания доменов, Extended Key Usage для серверной аутентификации, AIA для OCSP.
- Сертификаты УЦ — Basic Constraints (CA=TRUE), Key Usage (keyCertSign, cRLSign), Name Constraints для корпоративных PKI.
- Электронная подпись — Key Usage (digitalSignature, nonRepudiation), Extended Key Usage (emailProtection).
- Кодовая подпись (code signing) — Extended Key Usage (codeSigning), часто с ограничением на время.
- Смарт-карты и аутентификация — использование Subject Directory Attributes для хранения ролей и прав.
Безопасность и критика
Некорректная установка расширений может привести к уязвимостям. Например, если сертификат УЦ не содержит Basic Constraints с CA=TRUE, любой сертификат может быть использован для выпуска других сертификатов, что нарушает иерархию доверия. Также опасно делать критическими расширения, которые не поддерживаются всеми приложениями — это может привести к отказу в обработке легитимных сертификатов.
В российской практике использование расширений регламентируется ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012, а также стандартами Минцифры для PKI государственных органов. В частности, в сертификатах усиленной квалифицированной электронной подписи (УКЭП) обязательно указываются расширения для использования ключа и политики.
Источники
- ITU-T Recommendation X.509 (2019) — Information technology — Open systems interconnection — The Directory: Public-key and attribute certificate frameworks.
- RFC 5280 (2008) — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.
- RFC 6818 (2013) — Updates to the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.
- ГОСТ Р 34.10-2012 — Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи.
- ГОСТ Р 34.11-2012 — Информационная технология. Криптографическая защита информации. Функция хэширования.
BFOmetr — база данных и аналитика по компаниям России.
На главную BFOmetr →