How to Generate a CSR on Tomcat

This tutorial shows you how to generate a CSR (Certificate Signing Request) for Apache Tomcat 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. 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.

What you will need

• A Java installation (JDK or JRE) so the keytool command is available. Confirm with keytool -help.
• Shell or terminal access on the 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 domains you want to cover (for 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 Tomcat.

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

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

What the flags mean:

• -alias tomcat: the entry name inside the keystore. Pick a label you will recognize (often tomcat 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.
• -keyalg RSA -keysize 2048: a 2048-bit RSA key is the current public minimum. For new keystores, 3072 bits is a reasonable upgrade for longer-lived keys. 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 remember, 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 Tomcat’s server.xml. 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: 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.
• Organization (O): the full legal name of your company, for example Your Company LLC.
• 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 tomcat \
  -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 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 you used in Step 1:

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

What the flags mean:

• -alias tomcat: 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 bare 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 Tomcat 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 TLS will not work. 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, tomcat).
• The keystore file path (for example yourdomain.p12).
• 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.

After the CA validates your request and issues the certificate, continue with how to install your SSL certificate on Tomcat. You will import the signed certificate back into the same alias in the same keystore, and then point Tomcat’s HTTPS connector at that keystore.