Cómo generar un CSR en servidores JBoss

Este tutorial te muestra cómo generar un CSR (Certificate Signing Request) en JBoss EAP y WildFly utilizando la utilidad Java keytool. El proceso consta de dos comandos: primero keytool -genkeypair crea un almacén de claves (keystore) y una clave privada bajo un alias elegido, luego keytool -certreq exporta el CSR correspondiente con los Subject Alternative Names que la CA emitirá. El mismo alias se reutiliza más adelante cuando importas el certificado firmado, de modo que la clave, el CSR y el eventual certificado quedan todos en un mismo lugar.

Nota sobre versiones: el JBoss moderno es Red Hat JBoss Enterprise Application Platform (EAP) 8, lanzado en febrero de 2024 y basado en el proyecto ascendente WildFly (WildFly 41, lanzado en julio de 2026, es la versión comunitaria actual). Ambos configuran HTTPS a través del subsistema elytron y el https-listener de Undertow; la configuración más antigua del conector Tomcat o Jetty que se muestra en guías heredadas ya no aplica. Sin embargo, el paso del CSR en sí es idéntico en todas las versiones recientes porque es una simple operación de Java keytool.

Lo que necesitarás

• Una instalación de Java (JDK o JRE) para que el comando keytool esté disponible. JBoss EAP 8.0 se ejecuta en Java 11 (obsoleto) o 17, EAP 8.1 añade Java 21, y WildFly 41 se ejecuta en Java 17, 21 o 25 (Java 11 ya no es compatible en el proyecto ascendente). Confírmalo con keytool -help.
• Acceso a shell o terminal en el servidor JBoss que alojará la clave privada. La clave privada debe permanecer en este servidor.
• El nombre de dominio completamente cualificado (FQDN) exacto que deseas proteger, por ejemplo www.tudominio.com, más cualquier nombre de host adicional que quieras cubrir en el campo SAN.
• Los datos legales de tu organización (país, estado, localidad, nombre de la organización) para el Distinguished Name del CSR.

Paso 1: Crear el keystore y la clave privada

Si ya generaste tu CSR, pasa directamente a enviar el CSR y luego a instalar tu certificado SSL en JBoss.

Abre una terminal en el servidor JBoss y crea un nuevo keystore en formato PKCS12. PKCS12 es el estándar moderno y portátil (RFC 7292) y ha sido el formato de keystore predeterminado en Java desde JDK 9; el formato propietario más antiguo JKS está obsoleto. Ejecuta:

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

Qué significan los indicadores:

• -alias jboss: el nombre de la entrada dentro del keystore. Elige una etiqueta que reconozcas (a menudo jboss, server, o tu dominio). Anótalo. Debes reutilizar este alias exacto cuando generes el CSR y de nuevo cuando importes el certificado firmado. Usar un alias diferente al importar es el error de keytool más común.
• -keyalg RSA -keysize 2048: una clave RSA de 2048 bits es el mínimo público actual. Para keystores nuevos que pretendas conservar durante varios años, 3072 bits es una actualización razonable. La mayoría de las CA públicas también aceptan ECDSA (-keyalg EC -groupname secp256r1) si prefieres una clave más pequeña y rápida. La opción -groupname requiere JDK 13 o posterior; en Java 11 usa en su lugar -keyalg EC -keysize 256, que selecciona la misma curva secp256r1. keytool rechaza ambas opciones en el mismo comando.
• -storetype PKCS12: fuerza el keystore moderno PKCS12. La extensión correspondiente es .p12 (o .pfx).
• -keystore yourdomain.p12: el archivo de keystore a crear. Reemplaza el nombre con algo que reconozcas y mantén este archivo seguro; contiene tu clave privada.
• -validity 825: cuánto tiempo es válido el certificado de marcador de posición autofirmado dentro del keystore. El certificado firmado por la CA lo reemplaza más tarde, así que el valor exacto no afecta la vida útil en producción.

keytool solicita entonces una contraseña de keystore. Elige una contraseña segura y guárdala en tu gestor de secretos: la necesitarás para cada comando posterior de keytool y para el credential-reference de Elytron que configurarás en JBoss. Con los keystores PKCS12 la contraseña de la clave es igual a la contraseña del keystore, así que solo hay una contraseña que recordar.

Paso 2: Introducir los detalles de tu organización (DN)

keytool ahora solicita el Distinguished Name (DN): los campos de identidad que van dentro del CSR. Responde a cada indicación con el valor exacto y legal de tu organización. La puntuación y la precisión importan, porque una CA rechazará las discrepancias frente a registros públicos de empresas.

• Nombre y apellido (CN): esta es la redacción de keytool, pero corresponde al campo Common Name. Introduce el FQDN exacto que estás protegiendo, por ejemplo www.tudominio.com, o un comodín como *.tudominio.com. No introduzcas el nombre de una persona.
• Unidad organizativa (OU): este campo ya no lo emiten las CA públicas y es mejor dejarlo fuera. Ten en cuenta que pulsar Intro no lo deja vacío: keytool sustituye su propio valor predeterminado, así que el DN termina llevando OU=Unknown, que luego pasa al CSR. Para omitir realmente el campo, usa la forma no interactiva -dname que se muestra a continuación y deja la OU fuera de la cadena.
• Organización (O): el nombre legal completo de tu empresa, por ejemplo Your Company LLC. Los certificados OV y EV lo requieren; para los certificados DV muchas CA lo aceptan como informativo, así que rellenarlo es más seguro que dejarlo en blanco.
• Ciudad o localidad (L): el nombre completo de la ciudad, por ejemplo San Jose. No lo abrevies.
• Estado o provincia (ST): el nombre completo del estado o provincia, por ejemplo California. No uses un código de dos letras.
• Código de país (C): el código de país ISO de dos letras, por ejemplo US, GB, DE.

Tras la última indicación, keytool muestra un resumen como CN=www.tudominio.com, OU=Unknown, O=Your Company LLC, L=San Jose, ST=California, C=US. Escribe yes para confirmar. El archivo de keystore ahora existe con una entrada: tu alias, que contiene la clave privada y un certificado de marcador de posición autofirmado.

Si prefieres un comando no interactivo, pasa el DN en línea y omite las indicaciones:

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

Paso 3: Generar el CSR con SAN

Los navegadores y clientes TLS modernos validan los certificados contra la extensión Subject Alternative Name (SAN), no solo contra el Common Name. Solicita los SAN directamente en el CSR para que la CA los incluya en el certificado emitido. Usa el mismo alias y keystore del Paso 1:

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

Qué significan los indicadores:

• -alias jboss: debe coincidir con el alias del Paso 1. Este es el alias cuya clave privada firma la solicitud.
• -keystore yourdomain.p12: debe coincidir con el keystore del Paso 1.
• -file yourdomain.csr: el nombre de archivo de salida para el CSR.
• -ext san=dns:…: la extensión Subject Alternative Name. Enumera cada nombre de host que el certificado debe cubrir, incluyendo tanto el dominio raíz (tudominio.com) como el subdominio www. Añade más entradas separadas por comas, por ejemplo dns:api.tudominio.com.

keytool solicita la contraseña del keystore y escribe el CSR en yourdomain.csr en el directorio actual.

Fundamental: conserva tu alias y keystore

El error de keytool más común en JBoss es importar el certificado firmado bajo un nuevo alias. Hacer eso almacena el certificado como una entrada de confianza independiente sin ninguna clave privada asociada, y el gestor de claves de Elytron no podrá iniciar una sesión TLS. Importa siempre la respuesta firmada de vuelta al mismo alias que contiene la clave privada (el alias del Paso 1).

Anota estos tres valores ahora, antes de cerrar la terminal:

• El alias (en esta guía, jboss).
• La ruta del archivo de keystore (por ejemplo yourdomain.p12; en JBoss esto normalmente se encuentra en $JBOSS_HOME/standalone/configuration/).
• La contraseña del keystore.

Si no estás seguro de qué alias contiene tu clave, enumera el contenido del keystore y busca la entrada cuyo tipo sea PrivateKeyEntry:

keytool -list -v -keystore yourdomain.p12

Paso 4: Verificar el CSR antes de enviarlo

Detecta errores tipográficos en el DN o SAN faltantes antes de que la CA los valide. Imprime el CSR con keytool:

keytool -printcertreq -file yourdomain.csr

O, si tienes OpenSSL instalado, puedes usarlo en su lugar:

openssl req -noout -text -in yourdomain.csr

Confirma tres cosas en la salida: el Subject muestra tu DN exacto, el Subject Alternative Name enumera cada nombre de host que necesitas, y el tamaño de Public-Key coincide con lo que solicitaste (RSA de 2048 bits, o lo que hayas elegido). También puedes pegar el CSR en nuestro Decodificador de CSR para hacer la misma comprobación en un navegador.

Paso 5: Enviar el CSR a tu Autoridad Certificadora

Abre yourdomain.csr en cualquier editor de texto. El archivo es texto plano, que comienza con -----BEGIN NEW CERTIFICATE REQUEST----- y termina con -----END NEW CERTIFICATE REQUEST-----. La palabra NEW es lo que escribe keytool, y es normal: el contenido es una solicitud PKCS#10 estándar que toda CA acepta. Copia el bloque completo, incluidas esas líneas de encabezado y pie, y pégalo en el campo del CSR durante el proceso de compra con tu CA. En Windows, usa Ctrl + A y luego Ctrl + C para capturar todo el texto; en macOS, usa Cmd + A y luego Cmd + C.

Haz una copia de seguridad del archivo de keystore antes de hacer cualquier otra cosa. Si pierdes yourdomain.p12 también pierdes la clave privada, lo que significa que el certificado firmado que devuelva la CA será inutilizable y tendrás que empezar de nuevo con un CSR nuevo.

Después de que la CA valide tu solicitud y emita el certificado, continúa con cómo instalar tu certificado SSL en JBoss. Importarás el certificado firmado de vuelta al mismo alias en el mismo keystore, y luego harás referencia a ese keystore desde un key-store, key-manager y server-ssl-context de Elytron conectados al https-listener de Undertow.

¿Puedo reutilizar un CSR para una renovación?

Puedes, pero la mejor práctica de seguridad es generar un keystore nuevo, una clave privada nueva y un CSR nuevo para cada certificado. Una nueva clave para cada renovación limita el impacto si la clave anterior llega a verse comprometida, y el proceso es el mismo: ejecuta keytool -genkeypair y keytool -certreq contra un nuevo archivo de keystore. La vida útil de los certificados TLS públicos se está reduciendo bajo las normas del CA/Browser Forum (200 días a partir del 15 de marzo de 2026, bajando a 100 días en 2027 y a 47 días en 2029), así que planifica ciclos de CSR más frecuentes, o automatiza la emisión mediante ACME donde tu CA lo admita.