Запрос на создание сертификата

Запрос на создание сертификата (англ. Certificate Signing Request, CSR) — это структурированное сообщение, которое субъект (например, сервер, веб-сайт или пользователь) отправляет в удостоверяющий центр (УЦ) для получения цифрового сертификата. CSR содержит открытый ключ заявителя, информацию о его идентификации (доменное имя, организация, страна) и подписывается закрытым ключом, чтобы подтвердить владение соответствующим ключом. Запрос на создание сертификата является первым шагом в процессе выпуска сертификата X.509, используемого для защиты соединений по протоколу TLS/SSL, электронной подписи и аутентификации.

Структура и формат

CSR создаётся в соответствии со стандартом PKCS #10 (Public-Key Cryptography Standards #10), определённым в RFC 2986. Основными элементами запроса являются:

• Информация о субъекте (Subject Distinguished Name, DN) — набор полей, идентифицирующих владельца сертификата. Обязательные поля включают:
• Common Name (CN) — доменное имя (например, example.com) или имя пользователя.
• Organization (O) — название организации (для сертификатов Extended Validation (EV) и Organization Validation (OV)).
• Country (C) — двухбуквенный код страны по ISO 3166-1.
• State or Province (ST) — регион или область.
• Locality (L) — город или населённый пункт.

• Открытый ключ — криптографический ключ, который будет включён в сертификат. Обычно используется алгоритм RSA (с длиной ключа 2048 или 4096 бит), ECDSA (на эллиптических кривых, например, P-256) или EdDSA (например, Ed25519).

• Подпись — хеш запроса, зашифрованный закрытым ключом заявителя. УЦ проверяет эту подпись, чтобы убедиться, что заявитель действительно владеет соответствующим закрытым ключом.

• Дополнительные атрибуты (необязательно) — например, альтернативные имена субъекта (Subject Alternative Names, SAN) для поддержки нескольких доменов в одном сертификате, расширения X.509v3 (например, Key Usage, Extended Key Usage) или запрос на включение OCSP-стайплинга.

Формат CSR обычно кодируется в Base64 и заключается в блоки -----BEGIN CERTIFICATE REQUEST----- и -----END CERTIFICATE REQUEST-----. Это представление называется PEM-форматом. Также возможен бинарный формат DER.

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

Создание запроса на сертификат — это процедура, выполняемая на стороне заявителя (например, на веб-сервере, почтовом сервере или в криптопровайдере). Типичный алгоритм включает следующие шаги:

1. Генерация пары ключей — на устройстве заявителя создаются закрытый и открытый ключи. Закрытый ключ должен храниться в защищённом месте (например, в аппаратном модуле безопасности (HSM) или на локальном диске с ограниченным доступом). Открытый ключ включается в CSR.

1. Формирование DN и атрибутов — заявитель указывает идентификационные данные (доменное имя, организацию и т.д.). Для сертификатов с проверкой организации (OV) или расширенной проверкой (EV) эти данные должны точно соответствовать официальным документам.

1. Подпись запроса — заявитель подписывает CSR своим закрытым ключом. УЦ использует открытый ключ из запроса для проверки этой подписи.

1. Отправка в УЦ — CSR передаётся в удостоверяющий центр через веб-интерфейс, API или электронную почту. Некоторые УЦ предоставляют автоматизированные протоколы (например, ACME для Let’s Encrypt).

Типы запросов

CSR различаются по целям и объёму информации:

• Стандартный CSR (для SSL/TLS-сертификатов) — содержит доменное имя (CN) и, при необходимости, SAN. Используется для защиты веб-сайтов.
• CSR для сертификатов подписи кода — включает имя организации и может содержать расширения для подписи исполняемых файлов (Code Signing).
• CSR для клиентских сертификатов — идентифицирует пользователя (например, для аутентификации в VPN или электронной почте).
• CSR для сертификатов электронной подписи — может включать дополнительные атрибуты, такие как квалифицированный сертификат (ГОСТ Р 34.10-2012 в России).

Проверка удостоверяющим центром

После получения CSR удостоверяющий центр выполняет несколько этапов проверки:

1. Форматная проверка — УЦ проверяет, что запись соответствует стандарту PKCS #10, подпись корректна и срок действия ключа не истёк.

1. Верификация домена — для сертификатов Domain Validation (DV) УЦ проверяет, что заявитель контролирует домен (например, через электронное письмо на admin@example.com, DNS-запись или HTTP-файл).

1. Верификация организации — для сертификатов OV и EV УЦ запрашивает документы, подтверждающие регистрацию организации (выписка из ЕГРЮЛ, устав и т.д.). В России такие проверки проводятся в соответствии с Федеральным законом № 63-ФЗ «Об электронной подписи».

1. Проверка расширений — УЦ может отклонить запрос, если расширения (например, Key Usage) не соответствуют политике центра.

Если проверка успешна, УЦ подписывает открытый ключ заявителя своим закрытым ключом и выдаёт цифровой сертификат.

Применение в России

В Российской Федерации запросы на создание сертификата используются в рамках инфраструктуры открытых ключей (PKI) для:

• Квалифицированных сертификатов — выпускаются аккредитованными удостоверяющими центрами (например, Минцифры России, ФНС России) для электронной подписи в государственных информационных системах (Госуслуги, ЕГАИС, ЕФРСБ). Для них применяются российские криптографические стандарты ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012.
• SSL/TLS-сертификатов — для защиты сайтов государственных органов и коммерческих организаций. С 2022 года в России активно используются национальные удостоверяющие центры (например, «Национальный УЦ») из-за ограничений на импортные сертификаты.
• Сертификатов для электронного документооборота — например, для подписания счетов-фактур в системе «Диадок» или «1С-ЭДО».

Ограничения и риски

• Безопасность закрытого ключа — если закрытый ключ скомпрометирован, злоумышленник может подписать поддельный CSR и получить сертификат на чужое имя. Поэтому ключи должны генерироваться на защищённом устройстве (HSM) или храниться с использованием шифрования.
• Неверные данные — если в CSR указаны ошибочные данные (например, неверное доменное имя), УЦ может отклонить запрос или выпустить сертификат, который не будет работать.
• Срок действия — CSR не имеет срока действия, но подпись ключа может устареть. Рекомендуется генерировать новый CSR при каждом обращении за сертификатом.
• Зависимость от УЦ — если УЦ признан недействительным (например, из-за компрометации), все сертификаты, выпущенные на основе его CSR, становятся недоверенными.

Примеры использования

• Веб-сервер Apache — администратор генерирует CSR командой openssl req -new -key server.key -out server.csr, затем отправляет его в УЦ.
• Let’s Encrypt — автоматизированный протокол ACME создаёт CSR на стороне клиента (например, Certbot) и отправляет его в УЦ для получения бесплатного сертификата.
• КриптоПро CSP — в России для создания CSR под ГОСТ используется криптопровайдер КриптоПро CSP, который генерирует запрос в формате PKCS#10 с поддержкой российских алгоритмов.

Источники

• RFC 2986 — PKCS #10: Certification Request Syntax Specification.
• Федеральный закон № 63-ФЗ «Об электронной подписи» (Российская Федерация).
• ГОСТ Р 34.10-2012 — Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи.
• Документация OpenSSL — «req» command manual.
• Практическое руководство по PKI и цифровым сертификатам (издание 2021 г.).