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-сертификатах. Превращает сложные темы кибербезопасности в понятный, увлекательный контент. Вносите свой вклад в повышение уровня цифровой безопасности с помощью впечатляющих рассказов.