Открыть сервис
Главная → Блог → Certificate Signing Request

Certificate Signing Request

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

История и стандартизация

Концепция запроса на сертификат возникла с развитием инфраструктуры открытых ключей (PKI) в 1990-х годах. Первоначально процессы взаимодействия между заявителем и УЦ были неформализованы, что создавало проблемы совместимости. В 1993 году компания RSA Laboratories опубликовала стандарт PKCS#10, который стал де-факто основным форматом CSR. В 2000 году этот стандарт был принят IETF (Internet Engineering Task Force) как RFC 2986, что обеспечило его широкое распространение и поддержку во всех основных криптографических библиотеках и программных продуктах.

Параллельно существовали и другие форматы, такие как Signed Public Key and Challenge (SPKAC), используемый в браузерах Netscape, но со временем PKCS#10 вытеснил альтернативы, став единым промышленным стандартом.

Структура CSR

CSR, согласно PKCS#10, представляет собой закодированную последовательность ASN.1 (Abstract Syntax Notation One), которая затем обычно дополнительно кодируется в формат Base64 для удобства передачи (формат PEM). Структура включает три основных компонента:

  1. Информация о сертификате (CertificationRequestInfo):
  • Версия (Version): Обычно версия 0 (соответствует версии 1 сертификата X.509).
  • Имя субъекта (Subject Name): Различающееся имя (Distinguished Name, DN), которое будет присвоено сертификату. Включает атрибуты, такие как:
  • CN (Common Name) — основное доменное имя (например, example.com).
  • O (Organization) — название организации.
  • OU (Organizational Unit) — подразделение организации.
  • L (Locality) — город или населённый пункт.
  • ST (State) — штат или регион.
  • C (Country) — двухбуквенный код страны (например, RU для России).
  • Открытый ключ (Subject Public Key Info): Алгоритм и значение открытого ключа (обычно RSA, ECDSA или EdDSA) в формате SubjectPublicKeyInfo, описанном в RFC 5280.
  • Атрибуты (Attributes): Необязательное поле, которое может содержать дополнительные запросы, например:
  • extensions — запрос на включение в сертификат определённых расширений (например, Subject Alternative Name для указания дополнительных доменов).
  • challengePassword — пароль, который может быть использован УЦ для аутентификации последующих запросов на отзыв сертификата.
  1. Алгоритм подписи (Signature Algorithm): Идентификатор алгоритма, используемого для подписи CSR (например, sha256WithRSAEncryption).
  2. Значение подписи (Signature Value): Цифровая подпись, созданная закрытым ключом, соответствующим открытому ключу из запроса. Подпись покрывает всю структуру CertificationRequestInfo.

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

Процесс работы с CSR обычно включает следующие шаги:

  1. Генерация ключевой пары: На стороне заявителя (например, на веб-сервере) генерируется пара криптографических ключей: закрытый (секретный) и открытый (публичный). Закрытый ключ должен храниться в безопасном месте и никому не передаваться.
  2. Формирование CSR: С помощью специального инструмента (например, OpenSSL, утилиты IIS, панели управления хостингом) создаётся CSR, который включает открытый ключ и информацию о субъекте.
  3. Отправка в УЦ: CSR в формате PEM (текст, начинающийся с -----BEGIN CERTIFICATE REQUEST-----) отправляется в выбранный удостоверяющий центр.
  4. Валидация УЦ: УЦ проверяет подпись CSR (подтверждая, что заявитель владеет соответствующим закрытым ключом), а также проводит процедуры проверки личности и прав на домен (DV, OV, EV — в зависимости от типа сертификата).
  5. Выпуск сертификата: После успешной проверки УЦ создаёт цифровой сертификат X.509, подписывает его своим корневым или промежуточным сертификатом и возвращает заявителю.
  6. Установка: Полученный сертификат устанавливается на сервер вместе с соответствующим закрытым ключом.

Типы и применение

CSR используется для получения всех типов сертификатов X.509, включая:

  • SSL/TLS-сертификаты: Для защиты соединений с веб-сайтами (HTTPS), почтовыми серверами (SMTPS, IMAPS) и другими сетевыми службами.
  • Сертификаты подписи кода (Code Signing): Для цифровой подписи программного обеспечения, драйверов и скриптов.
  • Сертификаты электронной почты (S/MIME): Для шифрования и подписи электронных писем.
  • Клиентские сертификаты: Для аутентификации пользователей или устройств.
  • Сертификаты для VPN и Wi-Fi: Для аутентификации в корпоративных сетях (EAP-TLS).

Инструменты для работы с CSR

Наиболее распространённым инструментом для генерации и просмотра CSR является OpenSSL — кроссплатформенная криптографическая библиотека с открытым исходным кодом. Примеры команд:

  • Генерация закрытого ключа и CSR для сервера:

openssl req -new -newkey rsa:2048 -nodes -keyout server.key -out server.csr

  • Просмотр содержимого CSR:

openssl req -in server.csr -noout -text

Кроме OpenSSL, CSR могут создаваться встроенными средствами операционных систем (Windows Server, IIS), панелями управления хостингом (cPanel, Plesk) и специализированными программами (например, XCA, KeyStore Explorer).

Безопасность и ограничения

  • Закрытый ключ не должен отправляться: CSR содержит только открытый ключ. Передача закрытого ключа третьим лицам (включая УЦ) является грубой ошибкой безопасности, так как позволяет расшифровать трафик или подделать подпись.
  • Подпись CSR: Наличие подписи в CSR гарантирует, что заявитель владеет закрытым ключом, соответствующим открытому ключу в запросе. Это предотвращает атаки, при которых злоумышленник мог бы подменить открытый ключ.
  • Атрибуты и расширения: Не все УЦ поддерживают запросы на включение расширений через CSR. В таких случаях УЦ может игнорировать атрибуты или использовать свои собственные политики. В частности, расширение Subject Alternative Name (SAN) часто указывается непосредственно в CSR, но некоторые УЦ требуют его указания в отдельной форме.
  • Срок действия: CSR не имеет срока действия. Он может быть использован для запроса сертификата в любое время после генерации, при условии, что закрытый ключ остаётся действительным и не скомпрометирован.

Источники

  • RFC 2986 — PKCS #10: Certification Request Syntax Specification (Version 1.7).
  • RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.
  • RFC 2314 — PKCS #10: Certification Request Syntax Version 1.5.
  • Стандарт PKCS#10 (RSA Laboratories).
  • Документация OpenSSL.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы