bg-tutorials

Cómo generar un CSR en IBM HTTP Server

Esta guía muestra cómo generar un CSR (Certificate Signing Request) en IBM HTTP Server (IHS), y cómo hacer lo mismo en HCL Domino (anteriormente IBM Domino).

IBM HTTP Server almacena claves y certificados en una base de datos de claves CMS (un archivo .kdb más un stash .sth), que se gestiona con la herramienta gráfica IKEYMAN o con la utilidad de línea de comandos gskcapicmd del IBM Global Security Kit (GSKit) que se incluye con IHS.

Los pasos a continuación cubren ambas rutas en IHS 9.0.5.x (la versión compatible actual), y luego los dos flujos de CSR para HCL Domino: la base de datos clásica de Server Certificate Administration (mantenida para instalaciones antiguas) y la tarea moderna de Certificate Manager con certstore.nsf, que HCL recomienda a partir de Domino 12.

Generar un CSR en IBM HTTP Server

Si ya generó su CSR, vaya directamente a cómo instalar un certificado SSL en IBM HTTP Server.

Puede crear la solicitud de dos maneras en IHS: mediante la interfaz gráfica de IKEYMAN (la utilidad clásica de apuntar y hacer clic), o con gskcapicmd en la línea de comandos. Ambas escriben la clave privada en la misma base de datos de claves CMS y generan una solicitud PKCS #10 como un archivo .arm que se envía a su Autoridad de Certificación. Elija la interfaz gráfica en un escritorio o servidor con pantalla; elija la CLI en un servidor sin interfaz gráfica o cuando desee un script repetible.

Requisitos previos: IBM HTTP Server está instalado, GSKit está presente en el sistema (viene incluido dentro del paquete IHS), y el directorio bin de IHS está en su PATH o conoce su ruta completa (normalmente /opt/IBM/HTTPServer/bin/ en Linux/AIX, o C:Program FilesIBMHTTPServerbin en Windows). También necesita un directorio de trabajo donde escribir la nueva base de datos de claves y el archivo CSR, y un lugar donde registrar la contraseña de la base de datos de claves.

Método 1. Generar un CSR con IKEYMAN (GUI)

Paso 1. Crear una nueva base de datos de claves CMS (.kdb)

  • Inicie IKEYMAN. En Windows, abra Inicio > IBM HTTP Server > Start Key Management Utility. En Linux, AIX u otro sistema UNIX, ejecute ikeyman desde el directorio bin de IHS (por ejemplo, /opt/IBM/HTTPServer/bin/ikeyman); necesita una pantalla X11 funcional.
  • En el menú, seleccione Key Database File > New.
  • En el menú desplegable Key database type, seleccione CMS. Este es el formato que lee IBM HTTP Server.
  • En File Name, escriba un nombre para la nueva base de datos (por ejemplo, key.kdb).
  • En Location, indique una carpeta que pueda encontrar fácilmente (por ejemplo, /opt/IBM/HTTPServer/ssl/ en Linux, o C:IBMHTTPServerssl en Windows). Haga clic en OK.
  • Establezca una contraseña segura y luego marque Stash password to a file para que IKEYMAN escriba un archivo stash .sth coincidente junto al .kdb. IHS lee el stash al iniciarse, para que no tenga que escribir la contraseña cada vez que el servidor arranca. Haga clic en OK.

IKEYMAN crea dos archivos en esa carpeta: la base de datos en sí (key.kdb) y el stash (key.sth). Trate ambos como secretos. Mantenga sus permisos de archivo restringidos (legibles solo por el usuario de IHS) y haga copias de seguridad en una ubicación segura, porque no podrá recuperar la clave privada sin ellos.

Paso 2. Crear la solicitud de certificado

  • Con la nueva base de datos abierta, busque el menú desplegable Key database content y cámbielo a Personal Certificate Requests.
  • Haga clic en New. Se abre el cuadro de diálogo Create New Key and Certificate Request.

Rellene los campos usando solo caracteres ASCII estándar; las letras no latinas invalidan la solicitud:

  • Key Label: un identificador corto para este certificado dentro de la base de datos de claves, por ejemplo www.example.com. Hará referencia a esta etiqueta más adelante en httpd.conf con la directiva SSLServerCert.
  • Key Size: seleccione 2048. Este es el mínimo actual que aceptan todas las CA públicas. Elija 3072 o 4096 solo si su política requiere una clave más grande; la contrapartida es un negociado TLS ligeramente más lento.
  • Signature Algorithm: elija SHA256WithRSA (o más fuerte, como SHA384WithRSA). Evite todo lo que use SHA-1; las CA públicas no emitirán certificados con ese algoritmo.
  • Common Name: el nombre de dominio completamente calificado que desea proteger, por ejemplo www.example.com. Para un certificado comodín, coloque un asterisco delante del dominio raíz, por ejemplo *.example.com.
  • Organization: el nombre legal completo de su empresa, exactamente como está registrado. Obligatorio para certificados OV y EV; se ignora en DV.
  • Organizational Unit: este atributo está en desuso para certificados públicos (el CA/Browser Forum lo ha ido eliminando). Déjelo en blanco o escriba una etiqueta corta como IT.
  • Locality: el nombre completo de la ciudad (por ejemplo Seattle, no SEA).
  • State/Province: el nombre completo del estado o provincia (por ejemplo Washington, no WA).
  • Country: el código de país ISO de dos letras, por ejemplo US, GB o DE.
  • Subject Alternative Names (SAN): agregue todos los nombres de host que deben aparecer en el certificado, incluido el valor que puso en Common Name. Los navegadores modernos ignoran el Common Name y validan solo contra la lista SAN, por lo que un certificado con varios nombres necesita entradas aquí.
  • Enter the name of a file in which to store the certificate request: una ruta y nombre terminados en .arm, por ejemplo /opt/IBM/HTTPServer/ssl/www_example_com.arm. Guárdelo en la misma carpeta que la base de datos de claves para que ambos permanezcan juntos.

Haga clic en OK. IKEYMAN genera el par de claves dentro de la base de datos de claves, almacena la solicitud como una entrada pendiente y escribe el CSR PKCS #10 en el archivo .arm que nombró.

Paso 3. Copiar el CSR y enviarlo a la CA

Abra el archivo .arm con cualquier editor de texto (Notepad, vi, nano). Verá un bloque como este:

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

Seleccione todo el bloque, incluidas las líneas BEGIN y END, cópielo y péguelo en el campo CSR de su formulario de pedido. La clave privada permanece en la base de datos de claves del servidor; solo el texto del CSR sale de la máquina.

Método 2. Generar un CSR con gskcapicmd (CLI)

La utilidad gskcapicmd (a veces indicada como gskcmd para el wrapper de Java, o como gsk8capicmd_64 en instalaciones de GSKit de 64 bits) realiza el mismo trabajo que IKEYMAN sin necesidad de una sesión gráfica. Ejecútela desde el directorio bin de IHS.

Paso 1. Crear la base de datos de claves CMS y el archivo stash

Elija una carpeta para la base de datos de claves y luego ejecute:

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

Desglose de los argumentos:

  • -db: la ruta completa al nuevo archivo .kdb.
  • -pw: la contraseña que protege la base de datos de claves.
  • -type cms: el formato que lee IHS.
  • -stash: escribe un archivo stash .sth coincidente junto a la base de datos para que IHS pueda leerlo sin pedir confirmación al iniciarse.

En la línea de comandos, la contraseña es visible en los listados de procesos y en el historial de la shell. Después de que la base de datos exista, cambie la contraseña a una que no quede registrada en el historial con gskcapicmd -keydb -changepw, o pase la contraseña a través de una variable de entorno y luego elimínela.

Paso 2. Crear la solicitud de certificado

Genere el par de claves y el CSR PKCS #10 en un solo paso, con entradas SAN para cada nombre de host que desee en el certificado:

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

Desglose de los argumentos:

  • -label: el identificador para este certificado dentro de la base de datos de claves. Hágase referencia a él más adelante desde httpd.conf con la directiva SSLServerCert.
  • -dn: el Distinguished Name, escrito como una sola cadena con atributos separados por comas. Use CN= para el FQDN y el código ISO de dos letras en C=.
  • -size: 2048 es el mínimo. Use 3072 o 4096 solo si su política lo exige.
  • -sigalg: SHA256WithRSA (o SHA384WithRSA). No use SHA-1.
  • -san_dnsname: una lista separada por comas de todos los nombres de host que deben aparecer en el certificado. Incluya el valor del Common Name en esta lista. Los navegadores y la mayoría de las bibliotecas TLS validan solo el SAN, no el CN.
  • -file: la ruta donde gskcapicmd escribe el archivo CSR .arm.

Si necesita una clave ECDSA en lugar de RSA, reemplace -sigalg SHA256WithRSA por -sigalg SHA256WithECDSA y cambie -size para que coincida con su curva objetivo (-size 256 para P-256, -size 384 para P-384). Las curvas admitidas son secp256r1 (P-256), secp384r1 (P-384) y secp521r1 (P-521). El soporte de ECDSA en IHS se expone completamente solo a través de gskcapicmd; IKEYMAN no permite elegir ECDSA en versiones antiguas de IHS. Para ECDSA en una versión específica de IHS, siga las indicaciones de gestión de certificados de IBM.

Paso 3. Listar y verificar la solicitud

Confirme que la solicitud se agregó a la base de datos de claves:

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

Para leer el CSR y verificar el Common Name, las entradas SAN, el tamaño de la clave y el algoritmo de firma:

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

Luego abra el archivo .arm en un editor de texto, copie el bloque completo desde BEGIN NEW CERTIFICATE REQUEST hasta END NEW CERTIFICATE REQUEST, y envíelo en el formulario de pedido de su CA.

Verificar el CSR antes de enviarlo (opcional)

Si tiene OpenSSL instalado, ejecute esto en la misma máquina para confirmar el sujeto, la lista SAN y el tamaño de la clave:

openssl req -noout -text -in www_example_com.arm

¿Prefiere una herramienta en línea? Pegue el contenido de la solicitud en el Decodificador de CSR de SSL Dragon para leer los mismos detalles. Confirme que el Common Name coincida con el nombre de host que usarán los clientes y que todos los nombres de host requeridos aparezcan bajo Subject Alternative Name.

Después de que la CA emita su certificado

El certificado firmado debe volver a la misma base de datos de claves que generó el CSR, con la misma etiqueta. Recíbalo con la CLI:

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

O haga lo mismo en IKEYMAN, en Personal Certificates > Receive. Agregue primero los certificados raíz e intermedios como certificados de firmante, luego actualice httpd.conf con las directivas KeyFile y SSLServerCert y reinicie IHS. El procedimiento completo se explica en cómo instalar un certificado SSL en IBM HTTP Server.

Generar un CSR en HCL Domino

Nota: IBM Domino ahora es HCL Domino. HCL cerró la adquisición de la cartera de colaboración de IBM (incluyendo Notes/Domino) el 1 de julio de 2019. En Domino 12 y versiones posteriores, HCL recomienda la tarea Certificate Manager (con certstore.nsf y documentos TLS Credentials) para todo trabajo TLS nuevo. La base de datos clásica de Server Certificate Administration (CERTSRV.NSF) sigue funcionando en instalaciones antiguas y se documenta a continuación, pero las nuevas implementaciones deberían usar Certificate Manager.

Método A. Crear un CSR con Certificate Manager (Domino 12+ / 14.x)

  • Agregue la tarea CertMgr en su servidor designado como Certificate Manager para que cree certstore.nsf. En cada servidor Domino que necesite leer claves TLS, ejecute también CertMgr para que la base de datos se replique.
  • Abra certstore.nsf, vaya a TLS Credentials, y haga clic en Add TLS Credentials.
  • Host names: escriba el FQDN exacto que usarán los clientes, y agregue cada nombre de host adicional como Subject Alternative Name.
  • Servers with access: seleccione los servidores Domino que deben poder leer la clave privada.
  • Certificate Provider: elija Manual para cualquier CA de terceros. (Elija Let’s Encrypt solo si desea que CertMgr obtenga automáticamente un certificado gratuito emitido por ACME.)
  • Key type: elija RSA o ECDSA.
  • RSA: seleccione 2048 bits (o más si su política lo requiere).
  • ECDSA: elija una curva (P-256 o P-384; P-384 es la opción predeterminada indicada).
  • Haga clic en Submit Request. CertMgr genera el par de claves, firma el CSR, y el documento pasa a Status = Waiting.
  • Abra el documento, copie el valor de Certificate signing request (CSR) (o use la acción Copy CSR que aparece después del procesamiento), y pegue el bloque PEM en el formulario de pedido de su CA.

La clave privada permanece dentro de certstore.nsf, cifrada para los servidores que autorizó. Nunca la exporta. Cuando la CA emita su certificado, pegue el certificado firmado (junto con la cadena de emisión) de nuevo en el mismo documento TLS Credentials y CertMgr lo instalará por usted. La referencia completa está en la documentación de Certificate Manager de HCL.

Método B. Server Certificate Administration clásico (Domino heredado)

Use este método solo en versiones de Domino que aún dependen de archivos de key ring (.kyr + .sth). HCL lo marca como heredado a partir de Domino 12.

  • En el cliente Domino Administrator, abra Server Certificate Administration.
  • Elija Create Key Ring. Escriba un nombre de key ring y una contraseña segura.
  • Key Size: seleccione 2048 bits.
  • Complete el Distinguished Name:
  • Common Name: el FQDN que desea proteger, por ejemplo www.example.com.
  • Organization: el nombre legal completo de su empresa.
  • Organizational Unit: déjelo en blanco o escriba una etiqueta corta como IT (el atributo está en desuso para certificados públicos).
  • City or Locality: el nombre completo de la ciudad, por ejemplo Seattle.
  • State or Province: el nombre completo del estado, por ejemplo Washington.
  • Country: el código ISO de dos letras, por ejemplo US.
  • Revise los detalles y haga clic en Continue. Domino crea el archivo de key ring.
  • Elija Create Certificate Request. En Method, seleccione Paste into form on CA’s site. Domino muestra el texto del CSR.
  • Copie todo el bloque CSR (incluidas las líneas BEGIN y END) y péguelo en el formulario de pedido de su CA.

Los archivos de key ring clásicos no admiten entradas SAN a través de este cuadro de diálogo. Si necesita un certificado con varios nombres, pase a Certificate Manager (Método A) o genere el CSR fuera del servidor.

Preguntas frecuentes

¿Qué es una base de datos de claves CMS y por qué la necesita IHS?

IBM HTTP Server no lee archivos de clave y certificado PEM de la manera en que lo hace Apache estándar. Su pila TLS (mod_ibm_ssl, respaldada por GSKit) almacena claves, solicitudes de certificado y certificados emitidos en un único archivo de base de datos de claves CMS con extensión .kdb. Un archivo stash coincidente (.sth) contiene la contraseña de la base de datos en una forma que IHS puede leer al iniciarse. Se apunta IHS hacia la base de datos con la directiva KeyFile en httpd.conf y se hace referencia a un certificado específico dentro de ella con SSLServerCert.

¿Debo usar IKEYMAN o gskcapicmd?

Ambos escriben en la misma base de datos de claves, así que cualquiera de los dos funciona. IKEYMAN es conveniente en un escritorio o un servidor con pantalla X11, y lo guía a través del diálogo. gskcapicmd es la mejor opción en servidores sin interfaz gráfica, en automatización, y para claves ECDSA, que la interfaz gráfica no expone en versiones antiguas de IHS. Muchos administradores crean la base de datos con la CLI y usan IKEYMAN más tarde solo para inspeccionarla.

¿Qué hace el archivo stash (.sth)?

El archivo stash contiene la contraseña de la base de datos de claves en una forma ofuscada para que IBM HTTP Server pueda abrir la base de datos al iniciarse sin necesidad de una solicitud interactiva. No es cifrado: cualquiera con acceso de lectura al archivo puede recuperar la contraseña. Mantenga tanto el .kdb como el .sth legibles solo por el usuario de IHS, almacene la base de datos en el sistema de archivos local (no en un recurso compartido de lectura pública), y haga copias de seguridad del par en una ubicación segura.

¿Por qué gskcapicmd se llama gsk8capicmd_64 en mi sistema?

Ese es el binario que viene con GSKit 8.x de 64 bits, incluido con WebSphere Application Server 9 e IBM HTTP Server 9.0. GSKit 10 (incluido con WebSphere 10 y versiones posteriores) sigue la misma convención. El nombre gskcapicmd en esta guía es el wrapper distribuido por IHS que llama al binario correcto para su instalación; gsk8capicmd_64 es la misma herramienta con su nombre versionado. Ambos funcionan con la sintaxis mostrada anteriormente.

Ahorre un 10% en certificados SSL al realizar su pedido hoy mismo.

Emisión rápida, cifrado potente, 99,99% de confianza del navegador, asistencia dedicada y garantía de devolución del dinero en 25 días. Código del cupón: SAVE10

Una imagen detallada de un dragón en vuelo
Escrito por

Redactor de contenidos experimentado especializado en Certificados SSL. Transformar temas complejos de ciberseguridad en contenido claro y atractivo. Contribuir a mejorar la seguridad digital a través de narrativas impactantes.