Запрос на сертификат PKCS#10

Запрос на сертификат PKCS#10 — это стандартизированный формат сообщения, используемый для отправки заявки на выпуск цифрового сертификата в инфраструктуре открытых ключей (PKI). Формат определён в стандарте PKCS #10 (Public-Key Cryptography Standards #10), разработанном компанией RSA Laboratories. Запрос, также известный как CSR (Certificate Signing Request), содержит открытый ключ заявителя и информацию о его идентификационных данных, которые заверяются электронной подписью, созданной с использованием соответствующего закрытого ключа. Основное назначение PKCS#10 — обеспечить криптографически защищённую передачу данных от субъекта, запрашивающего сертификат, в удостоверяющий центр (УЦ).

Структура запроса

Согласно спецификации PKCS #10 версии 1.7 (RFC 2986), запрос на сертификат состоит из трёх основных частей:

1. Информация о сертификате (CertificationRequestInfo) — структура, содержащая:

• Версия (version) — целое число, указывающее версию формата. В актуальной реализации всегда равно 0 (соответствует версии 1.0).
• Имя субъекта (subject) — отличительное имя (Distinguished Name, DN) в формате X.500. Включает обязательные и необязательные атрибуты, такие как:
• Common Name (CN) — обычно доменное имя или имя владельца.
• Organization (O) — название организации.
• Organizational Unit (OU) — подразделение.
• Country (C) — двухбуквенный код страны (например, RU для России).
• Locality (L) — город или населённый пункт.
• State (ST) — регион или штат.
• Открытый ключ (subjectPublicKeyInfo) — алгоритм (например, RSA, ECDSA) и само значение открытого ключа.
• Атрибуты (attributes) — необязательный набор дополнительных полей, таких как:
• Запрошенные расширения (extensions) — например, указание использования ключа (Key Usage), альтернативные имена субъекта (Subject Alternative Name, SAN).
• Парольная фраза для отзыва сертификата (Challenge Password).
• Подпись (signatureAlgorithm и signature) — алгоритм подписи (например, sha256WithRSAEncryption) и сама подпись, вычисленная над информацией о сертификате с использованием закрытого ключа заявителя.

Структура кодируется в формате ASN.1 (Abstract Syntax Notation One) и обычно передаётся в виде двоичных данных DER (Distinguished Encoding Rules) или текстовой кодировки Base64 (PEM-формат).

Формат представления

Хотя стандарт PKCS#10 определяет внутреннюю структуру, на практике запросы часто передаются в виде текстового файла с расширением .csr или .p10. В PEM-формате файл начинается с заголовка -----BEGIN CERTIFICATE REQUEST----- и заканчивается строкой -----END CERTIFICATE REQUEST-----. Между ними располагается Base64-кодированное представление DER-структуры. Пример содержимого PEM-файла: `` -----BEGIN CERTIFICATE REQUEST----- MIICxjCCAa4CAQAw... -----END CERTIFICATE REQUEST----- ``

Процесс создания запроса

Создание запроса PKCS#10 включает следующие шаги:

1. Генерация ключевой пары — создаётся закрытый и открытый ключи (например, RSA длиной 2048 или 4096 бит, или ключ на основе эллиптических кривых ECDSA).
2. Формирование информации о сертификате — заполняются поля DN, открытый ключ и атрибуты.
3. Вычисление подписи — с помощью закрытого ключа создаётся цифровая подпись над структурой CertificationRequestInfo.
4. Кодирование — полученная структура кодируется в DER и, при необходимости, преобразуется в PEM-формат.

Генерация может выполняться как на стороне заявителя с помощью специализированного программного обеспечения (например, OpenSSL, certreq в Windows, инструменты в веб-серверах), так и через API удостоверяющих центров.

Обработка запроса удостоверяющим центром

После получения запроса УЦ выполняет следующие действия:

1. Проверка подписи — УЦ расшифровывает подпись с помощью открытого ключа из запроса и сравнивает её с хешем информации о сертификате. Если подпись верна, это подтверждает, что заявитель владеет соответствующим закрытым ключом.
2. Валидация данных — проверяется корректность атрибутов (например, соответствие формата DN, допустимость запрошенных расширений).
3. Верификация личности — в зависимости от политики УЦ может потребоваться подтверждение прав на домен (например, через электронную почту, DNS-запись или HTTP-токен) или юридическое удостоверение личности (для сертификатов с расширенной проверкой, EV).
4. Выпуск сертификата — если все проверки пройдены, УЦ создаёт цифровой сертификат X.509, подписывает его своим закрытым ключом и отправляет заявителю. В случае отказа УЦ возвращает сообщение об ошибке.

Расширения и атрибуты

Стандарт PKCS#10 поддерживает включение расширений через атрибут extensionRequest, определённый в PKCS #9. Наиболее часто используемые расширения:

• Subject Alternative Name (SAN) — указывает альтернативные имена (домены, IP-адреса), для которых будет действителен сертификат. Критически важно для современных сертификатов SSL/TLS, поддерживающих несколько доменов.
• Key Usage — определяет допустимые операции с ключом (например, цифровая подпись, шифрование ключей).
• Extended Key Usage (EKU) — уточняет назначение сертификата (например, серверная аутентификация, клиентская аутентификация, подпись кода).
• Basic Constraints — указывает, может ли сертификат быть удостоверяющим центром (CA:TRUE).

Применение

Запросы PKCS#10 широко используются в различных сферах:

• Веб-серверы — для получения сертификатов SSL/TLS, обеспечивающих защищённое соединение по протоколу HTTPS.
• Электронная подпись — для выпуска сертификатов подписи документов и кода.
• VPN и корпоративные сети — для аутентификации устройств и пользователей в инфраструктурах PKI.
• Почтовые системы — для подписи и шифрования электронной почты (S/MIME).
• Государственные информационные системы — в России, например, для получения сертификатов в рамках инфраструктуры электронного правительства или для работы с порталом «Госуслуги».

Особенности в России

В Российской Федерации применение PKCS#10 регулируется требованиями Федерального закона № 63-ФЗ «Об электронной подписи» и нормативными актами ФСБ России. Удостоверяющие центры, аккредитованные Минцифры России, обязаны поддерживать стандарт PKCS#10 для приёма заявок на выпуск сертификатов. При этом могут предъявляться дополнительные требования к алгоритмам подписи (например, использование ГОСТ Р 34.10-2012 для создания ключей и подписи) и к формату DN (обязательное указание ИНН, СНИЛС или ОГРН для юридических лиц). В таких случаях запросы PKCS#10 могут содержать атрибуты, соответствующие российским стандартам, но сама структура остаётся неизменной.

Критика и ограничения

Основные ограничения формата PKCS#10:

• Отсутствие механизма шифрования — запрос передаётся в открытом виде (за исключением подписи), что не защищает данные от перехвата. Для конфиденциальности рекомендуется передавать запросы по защищённым каналам (например, HTTPS).
• Негибкость атрибутов — стандарт не предусматривает вложенных структур, что усложняет добавление сложных метаданных.
• Зависимость от закрытого ключа — если закрытый ключ скомпрометирован до подписания запроса, злоумышленник может создать подложный запрос. Однако подпись запроса решает эту проблему, так как для её создания требуется знание закрытого ключа.

Альтернативы

Существуют и другие протоколы для запроса сертификатов, например:

• CMC (Certificate Management Messages over CMS) — более сложный стандарт (RFC 5272), поддерживающий шифрование запросов и дополнительные функции.
• SCEP (Simple Certificate Enrollment Protocol) — упрощённый протокол для автоматической выдачи сертификатов, часто используемый в корпоративных сетях.
• ACME (Automated Certificate Management Environment) — современный протокол, используемый Let's Encrypt и другими УЦ, который автоматизирует процесс проверки домена и выпуска сертификатов, не требуя ручного создания CSR.

Несмотря на конкуренцию, PKCS#10 остаётся наиболее распространённым форматом для ручного создания запросов на сертификаты благодаря своей простоте и широкой поддержке.

Источники

• RFC 2986 — PKCS #10: Certification Request Syntax Specification, Version 1.7.
• PKCS #10 v1.7 — RSA Laboratories, 2000.
• Федеральный закон от 06.04.2011 № 63-ФЗ «Об электронной подписи» (с изменениями).
• Методические рекомендации по использованию PKCS#10 в инфраструктуре электронного правительства РФ — Минцифры России, 2020.
• OpenSSL Documentation — req command manual.
• Microsoft Docs — Certreq command reference.