How to Generate a CSR on JBoss Servers

This tutorial shows you how to generate a CSR (Certificate Signing Request) on JBoss EAP and WildFly using the Java keytool utility. The flow is two commands: first keytool -genkeypair creates a keystore and a private key under a chosen alias, then keytool -certreq exports the matching CSR with the Subject Alternative Names the CA will issue. The same alias is reused later when you import the signed certificate, so the key, the CSR, and the eventual certificate all live in one place.

Note on versions: modern JBoss is Red Hat JBoss Enterprise Application Platform (EAP) 8, released in February 2024 and based on the upstream WildFly project (WildFly 35 is the current community release as of 2026). Both wire HTTPS through the elytron subsystem and the Undertow https-listener; the older Tomcat or Jetty connector configuration shown in legacy guides no longer applies. The CSR step itself, however, is identical across all recent versions because it is a plain Java keytool operation.

What you will need

• A Java installation (JDK or JRE) so the keytool command is available. JBoss EAP 8.0 runs on Java 11 (deprecated) or 17, EAP 8.1 adds Java 21, and WildFly 35 requires Java 17 or 21 (Java 11 was dropped in WildFly 35). Confirm with keytool -help.
• Shell or terminal access on the JBoss server that will host the private key. The private key must stay on this server.
• The exact fully qualified domain name (FQDN) you want to secure, for example www.yourdomain.com, plus any additional hostnames you want to cover in the SAN field.
• Your organization’s legal details (country, state, locality, organization name) for the CSR’s Distinguished Name.

Step 1: Create the keystore and the private key

If you already generated your CSR, skip ahead to submit the CSR and then to install your SSL certificate on JBoss.

Open a terminal on the JBoss server and create a new keystore in PKCS12 format. PKCS12 is the modern, portable standard (RFC 7292) and has been the default keystore format in Java since JDK 9; the older proprietary JKS format is deprecated. Run:

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

What the flags mean:

• -alias jboss: the entry name inside the keystore. Pick a label you will recognize (often jboss, server, or your domain). Write it down. You must reuse this exact alias when you generate the CSR and again when you import the signed certificate. Using a different alias on import is the single most common keytool mistake.
• -keyalg RSA -keysize 2048: a 2048-bit RSA key is the current public minimum. For new keystores you intend to keep for several years, 3072 bits is a reasonable upgrade. Most public CAs also accept ECDSA (-keyalg EC -groupname secp256r1) if you prefer a smaller, faster key.
• -storetype PKCS12: forces the modern PKCS12 keystore. The matching extension is .p12 (or .pfx).
• -keystore yourdomain.p12: the keystore file to create. Replace the name with something you will recognize, and keep this file safe; it contains your private key.
• -validity 825: how long the self-signed placeholder certificate inside the keystore is valid. The signed certificate from the CA replaces it later, so the exact value does not affect production lifetime.

keytool then prompts for a keystore password. Choose a strong password and store it in your secrets manager: you will need it for every later keytool command and for the Elytron credential-reference you will configure in JBoss. With PKCS12 keystores the key password equals the keystore password, so there is only one password to remember.

Step 2: Enter your organization details (DN)

keytool now asks for the Distinguished Name (DN): the identity fields that go into the CSR. Answer each prompt with the exact, legal value for your organization. Punctuation and accuracy matter, because a CA will reject mismatches against public business records.

• First and last name (CN): this is keytool’s wording, but it is the Common Name field. Enter the exact FQDN you are securing, for example www.yourdomain.com, or a wildcard such as *.yourdomain.com. Do not enter a person’s name.
• Organizational unit (OU): this field is no longer issued by public CAs and is best left blank. Press Enter to skip it.
• Organization (O): the full legal name of your company, for example Your Company LLC. OV and EV certificates require this; for DV certificates many CAs accept it as informational, so populating it is safer than leaving it blank.
• City or locality (L): the full city name, for example San Jose. Do not abbreviate.
• State or province (ST): the full state or province name, for example California. Do not use a two-letter code.
• Country code (C): the two-letter ISO country code, for example US, GB, DE.

After the last prompt, keytool shows a summary like CN=www.yourdomain.com, OU=, O=Your Company LLC, L=San Jose, ST=California, C=US. Type yes to confirm. The keystore file now exists with one entry: your alias, holding the private key and a self-signed placeholder certificate.

If you prefer a non-interactive command, pass the DN inline and skip the prompts:

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

Step 3: Generate the CSR with SAN

Modern browsers and TLS clients validate certificates against the Subject Alternative Name (SAN) extension, not against the Common Name alone. Request the SANs directly in the CSR so the CA includes them in the issued certificate. Use the same alias and keystore from Step 1:

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

What the flags mean:

• -alias jboss: must match the alias from Step 1. This is the alias whose private key signs the request.
• -keystore yourdomain.p12: must match the keystore from Step 1.
• -file yourdomain.csr: the output filename for the CSR.
• -ext san=dns:…: the Subject Alternative Name extension. List every hostname the certificate must cover, including both the apex (yourdomain.com) and the www subdomain. Add more entries comma-separated, for example dns:api.yourdomain.com.

keytool prompts for the keystore password and writes the CSR to yourdomain.csr in the current directory.

Critical: keep your alias and keystore

The single most common keytool mistake on JBoss is importing the signed certificate under a new alias. Doing that stores the certificate as a standalone trusted entry with no private key attached, and the Elytron key-manager will fail to start a TLS session. Always import the signed reply back into the same alias that holds the private key (the alias from Step 1).

Note these three values now, before you close the terminal:

• The alias (in this guide, jboss).
• The keystore file path (for example yourdomain.p12; on JBoss this typically lives in $JBOSS_HOME/standalone/configuration/).
• The keystore password.

If you are not sure which alias holds your key, list the keystore contents and look for the entry whose type is PrivateKeyEntry:

keytool -list -v -keystore yourdomain.p12

Step 4: Verify the CSR before you submit it

Catch typos in the DN or missing SANs before the CA validates them. Print the CSR with keytool:

keytool -printcertreq -file yourdomain.csr

Or, if OpenSSL is installed, you can use it instead:

openssl req -noout -text -in yourdomain.csr

Confirm three things in the output: the Subject shows your exact DN, the Subject Alternative Name lists every hostname you need, and the Public-Key size matches what you asked for (2048-bit RSA, or whatever you chose). You can also paste the CSR into our CSR Decoder for the same check in a browser.

Step 5: Submit the CSR to your Certificate Authority

Open yourdomain.csr in any text editor. The file is plain text, starting with —–BEGIN CERTIFICATE REQUEST—– and ending with —–END CERTIFICATE REQUEST—–. Copy the entire block, including those header and footer lines, and paste it into the CSR field during checkout with your CA. On Windows, use Ctrl + A then Ctrl + C to grab the full text; on macOS, use Cmd + A then Cmd + C.

Back up the keystore file before you do anything else. If you lose yourdomain.p12 you also lose the private key, which means the signed certificate the CA returns will be unusable and you will have to start over with a fresh CSR.

After the CA validates your request and issues the certificate, continue with how to install your SSL certificate on JBoss. You will import the signed certificate back into the same alias in the same keystore, then reference that keystore from an Elytron key-store, key-manager, and server-ssl-context wired into the Undertow https-listener.

ttps-listener, not into the deprecated legacy security-realm or Tomcat/Jetty connectors.

Can I reuse a CSR for a renewal?

You can, but the security best practice is to generate a fresh keystore, a fresh private key, and a fresh CSR for every certificate. A new key for each renewal limits the impact if the old key is ever compromised, and the process is the same: run keytool -genkeypair and keytool -certreq against a new keystore file. Public TLS certificate lifetimes are shrinking under CA/Browser Forum rules (200 days as of March 15, 2026, dropping to 100 days in 2027 and 47 days in 2029), so plan for more frequent CSR cycles, or automate issuance through ACME where your CA supports it.