Расширения сертификата: обзор

Расширения X.509 формируют дополнительный слой метаданных сертификата, который определяет ограничения использования ключа, контекст доверия и поведение в инфраструктуре PKI. В JavaScript-библиотеке Jsrsasign работа с этими расширениями строится вокруг разбора ASN.1-структуры сертификата и извлечения значений по OID, без необходимости вручную интерпретировать DER-деревья.


Каждое расширение сертификата представляет собой пару:

  • OID (Object Identifier) — идентификатор расширения
  • значение (value) — ASN.1-структура, зависящая от типа расширения

Расширения могут быть:

  • критическими (critical) — обязательны для интерпретации
  • некритическими — могут игнорироваться при отсутствии поддержки

Внутри сертификата они находятся в секции extensions структуры TBSCertificate.


Представление сертификата в Jsrsasign

В Jsrsasign сертификат обычно разбирается через объект:

var x509 = new X509();
x509.readCertPEM(pemString);

После загрузки сертификата становятся доступны методы для извлечения расширений. Библиотека не ограничивает пользователя фиксированным набором свойств — вместо этого используется доступ по OID.


Доступ к расширениям через OID

Основной механизм получения данных расширений:

var val = x509.getExtInfo("2.5.29.15"); // keyUsage

Каждое расширение идентифицируется стандартным OID:

  • 2.5.29.15 — Key Usage
  • 2.5.29.17 — Subject Alternative Name
  • 2.5.29.19 — Basic Constraints
  • 2.5.29.37 — Extended Key Usage

Возвращаемое значение обычно уже декодировано в удобную структуру (строка, массив или объект), но зависит от типа расширения.


Basic Constraints

Расширение Basic Constraints определяет, может ли сертификат выступать центром сертификации.

OID:

2.5.29.19

В Jsrsasign:

var bc = x509.getExtInfo("2.5.29.19");

Типичная структура результата:

{
  cA: true,
  pathLen: 2
}

Ключевые поля:

  • cA — флаг CA-сертификата
  • pathLen — максимальная глубина цепочки сертификации

Если cA = false, сертификат предназначен только для конечных сущностей.


Key Usage

Расширение Key Usage задаёт допустимые криптографические операции.

OID:

2.5.29.15

Извлечение:

var ku = x509.getExtInfo("2.5.29.15");

Часто возвращается массив или строковый список:

  • digitalSignature
  • keyEncipherment
  • dataEncipherment
  • keyCertSign
  • cRLSign
  • nonRepudiation

Пример интерпретации:

if (ku.includes("digitalSignature")) {
    // сертификат может использоваться для подписи данных
}

Это расширение критически важно для TLS и проверки цепочек доверия.


Extended Key Usage

Extended Key Usage (EKU) уточняет сценарии применения сертификата.

OID:

2.5.29.37

Извлечение:

var eku = x509.getExtInfo("2.5.29.37");

Типовые значения:

  • serverAuth (TLS сервер)
  • clientAuth (TLS клиент)
  • codeSigning
  • emailProtection
  • timeStamping

Пример:

if (eku.includes("serverAuth")) {
    // сертификат подходит для HTTPS сервера
}

EKU часто используется в сочетании с Key Usage, формируя строгие политики применения.


Subject Alternative Name (SAN)

Одно из самых важных расширений в современных TLS-конфигурациях.

OID:

2.5.29.17

Извлечение:

var san = x509.getExtInfo("2.5.29.17");

Структура может включать:

  • DNS имена
  • IP адреса
  • email
  • URI

Пример результата:

{
  dns: ["example.com", "www.example.com"],
  ip: ["192.168.0.1"]
}

В современных браузерах именно SAN определяет валидность домена, а не Common Name.


Subject Key Identifier и Authority Key Identifier

Эти расширения используются для построения цепочки доверия.

Subject Key Identifier

OID:

2.5.29.14
var ski = x509.getExtInfo("2.5.29.14");

Обычно возвращает хэш публичного ключа.

Authority Key Identifier

OID:

2.5.29.35
var aki = x509.getExtInfo("2.5.29.35");

Может содержать:

  • keyIdentifier
  • authorityCertIssuer
  • authorityCertSerialNumber

Эти поля позволяют сопоставить сертификат с его issuer в цепочке PKI.


Certificate Policies

Расширение Certificate Policies описывает правила использования сертификата.

OID:

2.5.29.32

Извлечение:

var policies = x509.getExtInfo("2.5.29.32");

Типичная структура:

[
  {
    policyOID: "2.23.140.1.2.1",
    cps: "https://ca.example/policy"
  }
]

Часто используется в EV/OV сертификатах и корпоративных PKI.


CRL Distribution Points

Определяет адреса списков отозванных сертификатов.

OID:

2.5.29.31
var crl = x509.getExtInfo("2.5.29.31");

Пример:

{
  urls: [
    "http://crl.example.com/root.crl"
  ]
}

Используется при проверке актуальности сертификата.


Интерпретация ASN.1 расширений

Jsrsasign работает поверх ASN.1-парсера KJUR.asn1. При необходимости можно анализировать расширения на низком уровне:

var hex = x509.hex;
var asn1 = ASN1HEX.parse(hex);

Каждое расширение в DER-структуре кодируется как:

Extension ::= SEQUENCE {
  extnID      OBJECT IDENTIFIER,
  critical    BOOLEAN DEFAULT FALSE,
  extnValue   OCTET STRING
}

extnValue дополнительно содержит вложенную ASN.1-структуру, которую библиотека декодирует автоматически.


Работа с неизвестными расширениями

Если OID не поддерживается явно, Jsrsasign обычно возвращает:

  • hex-строку
  • или raw ASN.1 объект

Пример:

var ext = x509.getExtInfo("1.2.3.4.5.6");

В этом случае требуется ручная интерпретация через ASN.1 декодирование.


Проверка критичности расширения

Некоторые методы позволяют определить, является ли расширение критическим:

var ext = x509.getExtInfo("2.5.29.19");
var isCritical = x509.getExtCritical("2.5.29.19");

Критичность влияет на поведение клиента: неизвестное критическое расширение должно приводить к отклонению сертификата.


Типовые сценарии анализа расширений

Проверка TLS-сертификата сервера

var eku = x509.getExtInfo("2.5.29.37");
var san = x509.getExtInfo("2.5.29.17");

if (!eku.includes("serverAuth")) {
    throw new Error("Not a server certificate");
}

if (!san.dns.includes("example.com")) {
    throw new Error("Domain mismatch");
}

Проверка CA-сертификата

var bc = x509.getExtInfo("2.5.29.19");

if (!bc.cA) {
    throw new Error("Not a CA certificate");
}

Особенности интерпретации в Jsrsasign

  • Декодирование расширений зависит от внутреннего ASN.1 парсера
  • Не все OID имеют высокоуровневую структуру
  • Часть расширений возвращается в виде строковых массивов
  • SAN и EKU уже нормализованы для удобного использования
  • Низкоуровневые данные доступны через hex и ASN.1 API

Расширяемость модели

Архитектура Jsrsasign позволяет добавлять поддержку новых расширений без изменения ядра библиотеки. Новые OID могут быть обработаны через пользовательские функции декодирования ASN.1, что особенно важно для частных PKI и корпоративных стандартов.