bg-tutorials

Как сгенерировать CSR на IBM HTTP Server

Это руководство показывает вам как сгенерировать CSR (Certificate Signing Request) на IBM HTTP Server (IHS), а также как выполнить ту же задачу на HCL Domino (ранее IBM Domino).

IBM HTTP Server хранит ключи и сертификаты в базе данных ключей CMS (файл .kdb плюс хранилище .sth), которой вы управляете с помощью графического инструмента IKEYMAN или утилиты командной строки gskcapicmd из IBM Global Security Kit (GSKit), поставляемого вместе с IHS.

Шаги ниже охватывают оба пути на IHS 9.0.5.x (текущий поддерживаемый релиз), а затем два потока CSR для HCL Domino: классическая база данных Server Certificate Administration (сохраняется для устаревших установок) и современная задача Certificate Manager с certstore.nsf, которую HCL рекомендует на Domino 12 и более поздних версиях.

Генерация CSR на IBM HTTP Server

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

Вы можете создать запрос двумя способами на IHS: через графический интерфейс IKEYMAN (классическая утилита с указанием и щелчком) или с помощью gskcapicmd в командной строке. Оба метода записывают приватный ключ в одну и ту же базу данных ключей CMS и создают запрос PKCS #10 в виде файла .arm, который вы отправляете в свой удостоверяющий центр. Выбирайте графический интерфейс на рабочем столе или сервере с дисплеем; выбирайте CLI на безголовом сервере или когда вам нужен повторяемый скрипт.

Предварительные требования: IBM HTTP Server установлен, GSKit присутствует в системе (он поставляется внутри пакета IHS), а каталог bin IHS находится в вашем PATH, или вы знаете его полный путь (обычно /opt/IBM/HTTPServer/bin/ на Linux/AIX, или C:Program FilesIBMHTTPServerbin на Windows). Вам также нужен рабочий каталог, куда вы можете записать новую базу данных ключей и файл CSR, и место, куда можно записать пароль базы данных ключей.

Способ 1. Создание CSR с помощью IKEYMAN (графический интерфейс)

Шаг 1. Создайте новую базу данных ключей CMS (.kdb)

  • Запустите IKEYMAN. На Windows откройте Пуск > IBM HTTP Server > Start Key Management Utility. На Linux, AIX или другой системе UNIX запустите ikeyman из каталога bin IHS (например, /opt/IBM/HTTPServer/bin/ikeyman); вам нужен рабочий дисплей X11.
  • В меню выберите Key Database File > New.
  • В раскрывающемся списке Key database type выберите CMS. Это формат, который читает IBM HTTP Server.
  • В поле File Name введите имя новой базы данных (например, key.kdb).
  • В поле Location укажите папку, которую вы сможете найти снова (например, /opt/IBM/HTTPServer/ssl/ на Linux или C:IBMHTTPServerssl на Windows). Нажмите OK.
  • Установите надёжный пароль, затем поставьте галочку Stash password to a file, чтобы IKEYMAN записал соответствующий файл хранилища .sth рядом с .kdb. IHS считывает хранилище при запуске, чтобы вам не приходилось вводить пароль каждый раз при старте сервера. Нажмите OK.

IKEYMAN создаёт два файла в этой папке: саму базу данных (key.kdb) и хранилище (key.sth). Относитесь к обоим как к секретным. Установите строгие права доступа к файлам (чтение только пользователем IHS) и создайте резервную копию в безопасном месте, потому что без них вы не сможете восстановить приватный ключ.

Шаг 2. Создайте запрос на сертификат

  • При открытой новой базе данных найдите раскрывающийся список Key database content и измените его на Personal Certificate Requests.
  • Нажмите New. Откроется диалоговое окно Create New Key and Certificate Request.

Заполните поля только стандартными символами ASCII; символы, отличные от латинских, приведут к сбою запроса:

  • Key Label: краткий идентификатор этого сертификата внутри базы данных ключей, например www.example.com. Позже вы будете ссылаться на эту метку в файле httpd.conf с помощью директивы SSLServerCert.
  • Key Size: выберите 2048. Это текущий минимум, который принимают все публичные удостоверяющие центры. Выбирайте 3072 или 4096 только если этого требует ваша политика; компромисс — немного более медленное установление TLS-соединения.
  • Signature Algorithm: выберите SHA256WithRSA (или сильнее, например SHA384WithRSA). Избегайте всего, что использует SHA-1; публичные удостоверяющие центры не будут выдавать сертификаты на его основе.
  • Common Name: полное доменное имя, которое вы хотите защитить, например www.example.com. Для сертификата с подстановочным знаком поставьте звёздочку перед вершиной домена, например *.example.com.
  • Organization: полное юридическое название вашей компании, точно как зарегистрировано. Требуется для сертификатов OV и EV; игнорируется для DV.
  • Organizational Unit: этот атрибут устарел для публичных сертификатов (CA/Browser Forum постепенно от него отказался). Оставьте поле пустым или введите краткую метку, например IT.
  • Locality: полное название города (например, Seattle, а не SEA).
  • State/Province: полное название штата или провинции (например, Washington, а не WA).
  • Country: двухбуквенный код страны ISO, например US, GB или DE.
  • Subject Alternative Names (SAN): добавьте каждое имя хоста, которое должно появиться на сертификате, включая значение, указанное в Common Name. Современные браузеры игнорируют Common Name и проверяют только список SAN, поэтому для сертификата с несколькими именами здесь нужны соответствующие записи.
  • Enter the name of a file in which to store the certificate request: путь и имя, заканчивающееся на .arm, например /opt/IBM/HTTPServer/ssl/www_example_com.arm. Сохраните его в той же папке, что и базу данных ключей, чтобы они оставались вместе.

Нажмите OK. IKEYMAN генерирует пару ключей внутри базы данных ключей, сохраняет запрос как ожидающую запись и записывает CSR в формате PKCS #10 в указанный вами файл .arm.

Шаг 3. Скопируйте CSR и отправьте его в удостоверяющий центр

Откройте файл .arm в любом текстовом редакторе (Notepad, vi, nano). Вы увидите блок, подобный этому:

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIDXjCCAkYCAQAwgZQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApXYXNoaW5ndG9u
... (many lines of base64) ...
-----END NEW CERTIFICATE REQUEST-----

Выделите весь блок, включая строки BEGIN и END, скопируйте его и вставьте в поле CSR формы заказа. Приватный ключ остаётся в базе данных ключей на сервере; только текст CSR покидает машину.

Способ 2. Создание CSR с помощью gskcapicmd (CLI)

Утилита gskcapicmd (иногда указывается как gskcmd для обёртки Java, или как gsk8capicmd_64 на 64-разрядных установках GSKit) выполняет ту же работу, что и IKEYMAN, без графической сессии. Запустите её из каталога bin IHS.

Шаг 1. Создайте базу данных ключей CMS и файл хранилища

Выберите папку для базы данных ключей, затем запустите:

gskcapicmd -keydb -create 
  -db /opt/IBM/HTTPServer/ssl/key.kdb 
  -pw your_strong_password 
  -type cms 
  -stash

Разбор аргументов:

  • -db: полный путь к новому файлу .kdb.
  • -pw: пароль, защищающий базу данных ключей.
  • -type cms: формат, который считывает IHS.
  • -stash: записывает соответствующий файл хранилища .sth рядом с базой данных, чтобы IHS мог его считать без запроса при запуске.

В командной строке пароль виден в списках процессов и истории оболочки. После создания базы данных смените пароль на тот, который не записан в истории, с помощью gskcapicmd -keydb -changepw, или передайте пароль через переменную окружения и затем сбросьте её.

Шаг 2. Создайте запрос на сертификат

Сгенерируйте пару ключей и CSR в формате PKCS #10 за один шаг, с записями SAN для каждого имени хоста, которое вы хотите указать в сертификате:

gskcapicmd -certreq -create 
  -db /opt/IBM/HTTPServer/ssl/key.kdb 
  -pw your_strong_password 
  -label www.example.com 
  -dn "CN=www.example.com,O=Example Inc,L=Seattle,ST=Washington,C=US" 
  -size 2048 
  -sigalg SHA256WithRSA 
  -san_dnsname "www.example.com,example.com" 
  -file /opt/IBM/HTTPServer/ssl/www_example_com.arm

Разбор аргументов:

  • -label: идентификатор этого сертификата внутри базы данных ключей. Ссылайтесь на него позже из httpd.conf с помощью директивы SSLServerCert.
  • -dn: отличительное имя (Distinguished Name), записанное как одна строка с атрибутами, разделёнными запятыми. Используйте CN= для полного доменного имени и двухбуквенный код ISO в C=.
  • -size: 2048 — это минимум. Используйте 3072 или 4096 только если этого требует ваша политика.
  • -sigalg: SHA256WithRSA (или SHA384WithRSA). Не используйте SHA-1.
  • -san_dnsname: список через запятую каждого имени хоста, которое должно появиться на сертификате. Включите значение Common Name в этот список. Браузеры и большинство библиотек TLS проверяют только SAN, а не CN.
  • -file: путь, куда gskcapicmd записывает файл CSR .arm.

Если вам нужен ключ ECDSA вместо RSA, замените -sigalg SHA256WithRSA на -sigalg SHA256WithECDSA и измените -size в соответствии с вашей целевой кривой (-size 256 для P-256, -size 384 для P-384). Поддерживаемые кривые: secp256r1 (P-256), secp384r1 (P-384) и secp521r1 (P-521). Поддержка ECDSA в IHS полностью доступна только через gskcapicmd; IKEYMAN не позволяет выбрать ECDSA на более старых версиях IHS. Для ECDSA на конкретной версии IHS следуйте руководству IBM по управлению сертификатами.

Шаг 3. Просмотрите и проверьте запрос

Убедитесь, что запрос был добавлен в базу данных ключей:

gskcapicmd -certreq -list 
  -db /opt/IBM/HTTPServer/ssl/key.kdb 
  -pw your_strong_password

Чтобы прочитать CSR обратно и проверить Common Name, записи SAN, размер ключа и алгоритм подписи:

gskcapicmd -certreq -details 
  -db /opt/IBM/HTTPServer/ssl/key.kdb 
  -pw your_strong_password 
  -label www.example.com

Затем откройте файл .arm в текстовом редакторе, скопируйте полный блок от BEGIN NEW CERTIFICATE REQUEST до END NEW CERTIFICATE REQUEST и отправьте его на форме заказа удостоверяющего центра.

Проверьте CSR перед отправкой (необязательно)

Если у вас установлен OpenSSL, запустите это на той же машине, чтобы подтвердить субъект, список SAN и размер ключа:

openssl req -noout -text -in www_example_com.arm

Предпочитаете онлайн-инструмент? Вставьте содержимое запроса в CSR Decoder от SSL Dragon, чтобы прочитать те же данные. Убедитесь, что Common Name совпадает с именем хоста, которое будут использовать клиенты, и что каждое необходимое имя хоста присутствует в разделе Subject Alternative Name.

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

Подписанный сертификат должен вернуться в ту же базу данных ключей, которая создала CSR, с той же меткой. Получите его с помощью CLI:

gskcapicmd -cert -receive 
  -db /opt/IBM/HTTPServer/ssl/key.kdb 
  -pw your_strong_password 
  -file www_example_com.crt

Или сделайте то же самое в IKEYMAN в разделе Personal Certificates > Receive. Сначала добавьте корневой и промежуточный сертификаты как сертификаты подписантов, затем обновите httpd.conf директивами KeyFile и SSLServerCert и перезапустите IHS. Полная процедура описана в разделе как установить SSL-сертификат на IBM HTTP Server.

Генерация CSR на HCL Domino

Примечание: IBM Domino теперь называется HCL Domino. HCL завершила приобретение портфеля продуктов для совместной работы IBM (включая Notes/Domino) 1 июля 2019 года. На Domino 12 и более поздних версиях HCL рекомендует задачу Certificate Manager (с документами certstore.nsf и TLS Credentials) для всех новых задач TLS. Классическая база данных Server Certificate Administration (CERTSRV.NSF) по-прежнему работает для устаревших установок и описана ниже, но для новых развёртываний следует использовать Certificate Manager.

Способ A. Создание CSR с помощью Certificate Manager (Domino 12+ / 14.x)

  • Добавьте задачу CertMgr на выделенный сервер Certificate Manager, чтобы он создал certstore.nsf. На каждом сервере Domino, которому нужно читать ключи TLS, также запустите CertMgr, чтобы база данных реплицировалась.
  • Откройте certstore.nsf, перейдите в раздел TLS Credentials и нажмите Add TLS Credentials.
  • Host names: введите точное полное доменное имя, которое будут использовать клиенты, и добавьте каждое дополнительное имя хоста как Subject Alternative Name.
  • Servers with access: выберите серверы Domino, которые должны иметь возможность считывать приватный ключ.
  • Certificate Provider: выберите Manual для любого стороннего удостоверяющего центра. (Выбирайте Let’s Encrypt только если хотите, чтобы CertMgr автоматически получил бесплатный сертификат, выданный по протоколу ACME.)
  • Key type: выберите RSA или ECDSA.
  • RSA: выберите 2048 бит (или больше, если этого требует ваша политика).
  • ECDSA: выберите кривую (P-256 или P-384; P-384 указана как значение по умолчанию).
  • Нажмите Submit Request. CertMgr генерирует пару ключей, подписывает CSR, и документ переходит в состояние Status = Waiting.
  • Откройте документ, скопируйте значение Certificate signing request (CSR) (или используйте действие Copy CSR, которое появляется после обработки) и вставьте блок PEM в форму заказа вашего удостоверяющего центра.

Приватный ключ остаётся внутри certstore.nsf, зашифрованным для авторизованных вами серверов. Вы никогда его не экспортируете. Когда удостоверяющий центр выдаёт ваш сертификат, вставьте подписанный сертификат (вместе с цепочкой издателя) обратно в тот же документ TLS Credentials, и CertMgr установит его за вас. Полная справка находится в документации HCL по Certificate Manager.

Способ B. Классическое администрирование сертификатов сервера (устаревшая версия Domino)

Используйте этот способ только на версиях Domino, которые всё ещё полагаются на файлы связки ключей (.kyr + .sth). HCL помечает его как устаревший на Domino 12 и более поздних версиях.

  • В клиенте Domino Administrator откройте Server Certificate Administration.
  • Выберите Create Key Ring. Введите имя связки ключей и надёжный пароль.
  • Key Size: выберите 2048 бит.
  • Заполните отличительное имя:
  • Common Name: полное доменное имя, которое вы хотите защитить, например www.example.com.
  • Organization: полное юридическое название вашей компании.
  • Organizational Unit: оставьте пустым или введите краткую метку, например IT (атрибут устарел для публичных сертификатов).
  • City or Locality: полное название города, например Seattle.
  • State or Province: полное название штата, например Washington.
  • Country: двухбуквенный код ISO, например US.
  • Просмотрите данные и нажмите Continue. Domino создаёт файл связки ключей.
  • Выберите Create Certificate Request. В разделе Method выберите Paste into form on CA’s site. Domino отобразит текст CSR.
  • Скопируйте весь блок CSR (включая строки BEGIN и END) и вставьте его в форму заказа вашего удостоверяющего центра.

Классические файлы связки ключей не поддерживают записи SAN через это диалоговое окно. Если вам нужен сертификат с несколькими именами, перейдите к Certificate Manager (Способ A) или сгенерируйте CSR вне сервера.

Часто задаваемые вопросы

Что такое база данных ключей CMS и зачем она нужна IHS?

IBM HTTP Server не считывает файлы ключей и сертификатов PEM так, как это делает стандартный Apache. Его стек TLS (mod_ibm_ssl, работающий на базе GSKit) хранит ключи, запросы на сертификаты и выданные сертификаты в единой базе данных ключей CMS с расширением .kdb. Соответствующий файл хранилища (.sth) хранит пароль базы данных в форме, которую IHS может прочитать при запуске. Вы указываете IHS на базу данных с помощью директивы KeyFile в httpd.conf и ссылаетесь на конкретный сертификат внутри неё с помощью SSLServerCert.

Следует ли мне использовать IKEYMAN или gskcapicmd?

Оба инструмента записывают в одну и ту же базу данных ключей, поэтому подходит любой из них. IKEYMAN удобен на рабочем столе или сервере с дисплеем X11 и проводит вас через диалоговое окно. gskcapicmd — лучший выбор на безголовых серверах, в автоматизации и для ключей ECDSA, которые графический интерфейс не предоставляет на более старых версиях IHS. Многие администраторы создают базу данных с помощью CLI, а IKEYMAN используют позже только для её проверки.

Для чего нужен файл хранилища (.sth)?

Файл хранилища хранит пароль базы данных ключей в обфусцированной форме, чтобы IBM HTTP Server мог открыть базу данных при запуске без интерактивного запроса. Это не шифрование: любой, у кого есть доступ на чтение к файлу, может восстановить пароль. Обеспечьте, чтобы и .kdb, и .sth были доступны для чтения только пользователю IHS, храните базу данных в локальной файловой системе (не на общедоступном ресурсе), и создавайте резервную копию пары в безопасном месте.

Почему gskcapicmd называется gsk8capicmd_64 в моей системе?

Это бинарный файл, который поставляется с 64-разрядным GSKit 8.x, входящим в комплект WebSphere Application Server 9 и IBM HTTP Server 9.0. GSKit 10 (входящий в комплект WebSphere 10 и более поздних версий) следует той же схеме именования. Название gskcapicmd в этом руководстве — это распространяемая с IHS обёртка, которая вызывает нужный бинарный файл для вашей установки; gsk8capicmd_64 — это тот же инструмент под своим версионным названием. Оба варианта работают с указанным выше синтаксисом.

Сэкономьте 10% на SSL-сертификатах при заказе сегодня!

Быстрая выдача, надежное шифрование, 99,99% доверия к браузеру, специализированная поддержка и 25-дневная гарантия возврата денег. Код купона: SAVE10

Детальное изображение дракона в полете
Написано

Опытный автор контента, специализирующийся на SSL-сертификатах. Превращает сложные темы кибербезопасности в понятный, увлекательный контент. Вносите свой вклад в повышение уровня цифровой безопасности с помощью впечатляющих рассказов.

Avatar of Sergiu Rosca
Technical Review by Sergiu Rosca

Sergiu Rosca is the core web developer behind SSL Dragon. He manages the technical infrastructure, platform performance, and backend integrations that keep the site running smoothly and securely. At SSL Dragon, Sergiu shares practical insights on web development, site optimization, and technical troubleshooting.

All SSL Dragon installation guides are tested on live server environments and undergo a strict peer-review process to ensure your infrastructure remains secure. Read our full Editorial Policy.