Как сгенерировать CSR на серверах JBoss

Этот учебник показывает вам, как сгенерировать CSR (запрос на подпись сертификата) на JBoss EAP и WildFly с помощью утилиты Java keytool. Процесс состоит из двух команд: сначала keytool -genkeypair создает хранилище ключей и закрытый ключ под выбранным псевдонимом (alias), затем keytool -certreq экспортирует соответствующий CSR с альтернативными именами субъекта, которые выдаст CA. Тот же псевдоним позже используется повторно при импорте подписанного сертификата, поэтому ключ, CSR и итоговый сертификат хранятся в одном месте.

Примечание о версиях: современный JBoss — это Red Hat JBoss Enterprise Application Platform (EAP) 8, выпущенный в феврале 2024 года и основанный на проекте WildFly (WildFly 41, выпущенный в июле 2026 года, является текущим релизом сообщества). Обе версии настраивают HTTPS через подсистему elytron и https-listener Undertow; более старая конфигурация коннектора Tomcat или Jetty, показанная в устаревших руководствах, больше не применяется. Однако сам шаг создания CSR идентичен во всех последних версиях, поскольку это обычная операция Java keytool.

Что вам понадобится

• Установленная Java (JDK или JRE), чтобы команда keytool была доступна. JBoss EAP 8.0 работает на Java 11 (устаревшая) или 17, EAP 8.1 добавляет Java 21, а WildFly 41 работает на Java 17, 21 или 25 (Java 11 больше не поддерживается разработчиками). Проверьте с помощью keytool -help.
• Доступ к оболочке или терминалу на сервере JBoss, где будет храниться закрытый ключ. Закрытый ключ должен оставаться на этом сервере.
• Точное полное доменное имя (FQDN), которое вы хотите защитить, например www.yourdomain.com, а также любые дополнительные имена хостов, которые нужно включить в поле SAN.
• Юридические данные вашей организации (страна, штат, населенный пункт, название организации) для поля Distinguished Name в CSR.

Шаг 1: Создание хранилища ключей и закрытого ключа

Если вы уже сгенерировали свой CSR, переходите сразу к разделу отправка CSR, а затем к установке SSL-сертификата на JBoss.

Откройте терминал на сервере JBoss и создайте новое хранилище ключей в формате PKCS12. PKCS12 — это современный, портативный стандарт (RFC 7292), и он является форматом хранилища ключей по умолчанию в Java начиная с JDK 9; более старый проприетарный формат JKS считается устаревшим. Выполните:

keytool -genkeypair 
  -alias jboss 
  -keyalg RSA -keysize 2048 
  -storetype PKCS12 
  -keystore yourdomain.p12 
  -validity 825

Что означают флаги:

• -alias jboss: имя записи внутри хранилища ключей. Выберите метку, которую вы легко узнаете (часто jboss, server или ваш домен). Запишите его. Вы должны использовать этот же псевдоним при генерации CSR, а затем снова при импорте подписанного сертификата. Использование другого псевдонима при импорте — самая распространенная ошибка при работе с keytool.
• -keyalg RSA -keysize 2048: 2048-битный ключ RSA — это текущий общепринятый минимум. Для новых хранилищ ключей, которые вы планируете использовать несколько лет, разумным вариантом обновления будет 3072 бита. Большинство публичных CA также принимают ECDSA (-keyalg EC -groupname secp256r1), если вы предпочитаете меньший и более быстрый ключ. Опция -groupname требует JDK 13 или более позднюю версию; на Java 11 вместо этого используйте -keyalg EC -keysize 256, что выбирает ту же кривую secp256r1. keytool отклоняет обе опции в одной команде.
• -storetype PKCS12: принудительно задает современное хранилище ключей PKCS12. Соответствующее расширение — .p12 (или .pfx).
• -keystore yourdomain.p12: файл хранилища ключей, который будет создан. Замените имя на то, которое вы будете легко узнавать, и храните этот файл в безопасности; он содержит ваш закрытый ключ.
• -validity 825: как долго действителен самоподписанный заполняющий сертификат внутри хранилища ключей. Позже его заменит подписанный сертификат от CA, поэтому точное значение не влияет на срок службы в рабочей среде.

Затем keytool запрашивает пароль хранилища ключей. Выберите надежный пароль и сохраните его в вашем менеджере паролей: он понадобится вам для каждой последующей команды keytool и для credential-reference Elytron, который вы настроите в JBoss. В хранилищах ключей PKCS12 пароль ключа совпадает с паролем хранилища, поэтому запоминать нужно только один пароль.

Шаг 2: Ввод данных вашей организации (DN)

Теперь keytool запрашивает Distinguished Name (DN): поля идентификации, которые войдут в CSR. Отвечайте на каждый запрос точным юридическим значением для вашей организации. Пунктуация и точность важны, поскольку CA отклонит несоответствия с публичными деловыми записями.

• Имя и фамилия (CN): это формулировка keytool, но на самом деле это поле Common Name. Введите точное FQDN, которое вы защищаете, например www.yourdomain.com, или подстановочный знак вида *.yourdomain.com. Не вводите имя человека.
• Organizational unit (OU): это поле больше не выдается публичными CA, и лучше оставить его пустым. Обратите внимание, что нажатие Enter не оставляет поле пустым: keytool подставляет собственное значение по умолчанию, поэтому в DN в итоге появляется OU=Unknown, которое затем переносится в CSR. Чтобы действительно исключить это поле, используйте неинтерактивную форму -dname ниже и не указывайте OU в строке.
• Организация (O): полное юридическое название вашей компании, например Your Company LLC. Это требуется для сертификатов OV и EV; для DV-сертификатов многие CA принимают это как информационное поле, поэтому заполнить его безопаснее, чем оставить пустым.
• Город или населенный пункт (L): полное название города, например San Jose. Не используйте сокращения.
• Штат или область (ST): полное название штата или области, например California. Не используйте двухбуквенный код.
• Код страны (C): двухбуквенный код страны по стандарту ISO, например US, GB, DE.

После последнего запроса keytool показывает сводку вида CN=www.yourdomain.com, OU=Unknown, O=Your Company LLC, L=San Jose, ST=California, C=US. Введите yes для подтверждения. Теперь файл хранилища ключей существует с одной записью: ваш псевдоним, содержащий закрытый ключ и самоподписанный заполняющий сертификат.

Если вы предпочитаете неинтерактивную команду, передайте DN прямо в команде и пропустите запросы:

keytool -genkeypair 
  -alias jboss 
  -keyalg RSA -keysize 2048 
  -storetype PKCS12 
  -keystore yourdomain.p12 
  -dname "CN=www.yourdomain.com, O=Your Company LLC, L=San Jose, ST=California, C=US" 
  -validity 825

Шаг 3: Генерация CSR с SAN

Современные браузеры и TLS-клиенты проверяют сертификаты по расширению Subject Alternative Name (SAN), а не только по Common Name. Запросите SAN непосредственно в CSR, чтобы CA включил их в выданный сертификат. Используйте тот же псевдоним и хранилище ключей из шага 1:

keytool -certreq 
  -alias jboss 
  -keystore yourdomain.p12 
  -file yourdomain.csr 
  -ext san=dns:yourdomain.com,dns:www.yourdomain.com

Что означают флаги:

• -alias jboss: должен совпадать с псевдонимом из шага 1. Это псевдоним, чей закрытый ключ подписывает запрос.
• -keystore yourdomain.p12: должен совпадать с хранилищем ключей из шага 1.
• -file yourdomain.csr: имя выходного файла для CSR.
• -ext san=dns:…: расширение Subject Alternative Name. Перечислите все имена хостов, которые должен покрывать сертификат, включая корневой домен (yourdomain.com) и поддомен www. Добавляйте дополнительные записи через запятую, например dns:api.yourdomain.com.

keytool запрашивает пароль хранилища ключей и записывает CSR в файл yourdomain.csr в текущем каталоге.

Важно: сохраняйте псевдоним и хранилище ключей

Самая распространенная ошибка при работе с keytool на JBoss — импорт подписанного сертификата под новым псевдонимом. При этом сертификат сохраняется как отдельная доверенная запись без привязанного закрытого ключа, и менеджер ключей Elytron не сможет запустить сессию TLS. Всегда импортируйте подписанный ответ обратно в тот же псевдоним, который содержит закрытый ключ (псевдоним из шага 1).

Запишите эти три значения сейчас, прежде чем закрыть терминал:

• Псевдоним (в этом руководстве — jboss).
• Путь к файлу хранилища ключей (например, yourdomain.p12; на JBoss он обычно находится в $JBOSS_HOME/standalone/configuration/).
• Пароль хранилища ключей.

Если вы не уверены, какой псевдоним содержит ваш ключ, выведите список содержимого хранилища ключей и найдите запись типа PrivateKeyEntry:

keytool -list -v -keystore yourdomain.p12

Шаг 4: Проверка CSR перед отправкой

Выявите опечатки в DN или отсутствующие SAN до того, как CA проверит их. Выведите CSR с помощью keytool:

keytool -printcertreq -file yourdomain.csr

Или, если установлен OpenSSL, вы можете использовать его вместо этого:

openssl req -noout -text -in yourdomain.csr

Проверьте три момента в выводе: поле Subject показывает ваш точный DN, поле Subject Alternative Name перечисляет все необходимые имена хостов, а размер Public-Key соответствует тому, что вы запросили (2048-битный RSA или что вы выбрали). Вы также можете вставить CSR в наш Декодер CSR для той же проверки прямо в браузере.

Шаг 5: Отправка CSR в удостоверяющий центр

Откройте yourdomain.csr в любом текстовом редакторе. Файл представляет собой обычный текст, начинающийся со строки -----BEGIN NEW CERTIFICATE REQUEST----- и заканчивающийся строкой -----END NEW CERTIFICATE REQUEST-----. Слово NEW — это то, что записывает keytool, и это ожидаемо: содержимое представляет собой стандартный запрос PKCS#10, который принимают все CA. Скопируйте весь блок, включая эти начальную и конечную строки, и вставьте его в поле CSR при оформлении заказа у вашего CA. В Windows используйте Ctrl + A, а затем Ctrl + C, чтобы захватить весь текст; в macOS используйте Cmd + A, а затем Cmd + C.

Сделайте резервную копию файла хранилища ключей, прежде чем предпринимать что-либо еще. Если вы потеряете yourdomain.p12, вы также потеряете закрытый ключ, а это означает, что подписанный сертификат, который вернет CA, окажется непригодным для использования, и вам придется начинать заново с нового CSR.

После того как CA проверит ваш запрос и выдаст сертификат, переходите к разделу как установить SSL-сертификат на JBoss. Вы импортируете подписанный сертификат обратно в тот же псевдоним в том же хранилище ключей, а затем сошлетесь на это хранилище из key-store, key-manager и server-ssl-context Elytron, подключенных к https-listener Undertow.

Можно ли повторно использовать CSR при продлении?

Можно, но передовая практика безопасности заключается в создании нового хранилища ключей, нового закрытого ключа и нового CSR для каждого сертификата. Новый ключ при каждом продлении ограничивает последствия в случае компрометации старого ключа, а процесс остается тем же: выполните keytool -genkeypair и keytool -certreq для нового файла хранилища ключей. Сроки действия публичных TLS-сертификатов сокращаются согласно правилам CA/Browser Forum (200 дней по состоянию на 15 марта 2026 года, снижение до 100 дней в 2027 году и до 47 дней в 2029 году), поэтому планируйте более частые циклы обновления CSR или автоматизируйте выдачу через ACME, если ваш CA это поддерживает.