How to Generate a CSR code on Oracle Servers

This guide shows you how to generate a CSR (Certificate Signing Request) on Oracle servers. It covers the three Oracle products where you would create a CSR locally: Oracle Wallet Manager (or the modern orapki command), Oracle iPlanet Web Server, and Oracle WebLogic Server (Java keytool). Pick the section that matches your product, follow the steps, then submit the CSR to your Certificate Authority.

Generate a CSR on Oracle Wallet Manager

If you already generated your CSR, skip ahead to install your SSL certificate on Oracle. Otherwise, you have two options on Oracle Wallet Manager: the graphical Oracle Wallet Manager (OWM) interface or the modern orapki command line utility shipped with Oracle products. The orapki path is scriptable and is the option Oracle recommends for current deployments; OWM remains supported for the same operations.

Option A: Oracle Wallet Manager (GUI)

1. Open Oracle Wallet Manager. If you do not yet have a wallet, choose Wallet > New, set a strong password, and save it.
2. From the main menu, choose Operations > Add Certificate Request.
3. In the dialog, fill in the certificate request details exactly as your organization is legally registered:
   • Common Name (CN): the fully qualified domain name you want to secure, for example www.yourdomain.com, or a wildcard such as *.yourdomain.com. Do not enter a person’s name.
   • Organizational Unit (OU): public CAs no longer issue this field. Leave blank.
   • Organization (O): the full legal name of your company, for example Your Company LLC. For DV (Domain Validation) certificates, you can leave this blank.
   • Locality / City (L): the full city name where your company is registered, for example Seattle. Do not abbreviate.
   • State / Province (ST): the full state or province name, for example Washington. Do not use a two-letter code.
   • Country (C): the two-letter ISO country code, for example US, GB, DE.
   • Key Size: 2048 bits is the current public minimum. For new wallets you plan to keep for several years, 3072 bits is a reasonable upgrade.
4. Click OK. A confirmation window reports the successful CSR generation. The certificate node in the wallet navigation menu now shows the status Certificate: [Requested].
5. Back in the wallet view, choose Operations > Export Certificate Request, give the file a name (for example yourdomain.csr), and save it. Do not close or delete the wallet: it now contains the private key paired with this CSR.

Note: the Oracle Wallet Manager GUI does not expose a separate Subject Alternative Name (SAN) input. Modern browsers and TLS clients validate certificates against the SAN extension, not the Common Name, so list every hostname you need (for example yourdomain.com and www.yourdomain.com) in the SAN field on your Certificate Authority’s order form. The CA will add them to the issued certificate. If you use the orapki command line (Option B below), you can embed SANs directly in the CSR with the -addext_san flag.

Option B: orapki (command line)

The orapki utility ships with Oracle products (in the database, Fusion Middleware, and HTTP Server distributions) and is the scriptable alternative to OWM. The flow is two commands: create the wallet and key pair, then export the CSR.

Create an auto-login wallet and add a key pair:

orapki wallet create -wallet /etc/oracle/wallet -auto_login -pwd "YourStrongPassword"

orapki wallet add -wallet /etc/oracle/wallet \
  -dn "CN=www.yourdomain.com, O=Your Company LLC, L=Seattle, ST=Washington, C=US" \
  -keysize 2048 \
  -addext_san "DNS:yourdomain.com,DNS:www.yourdomain.com" \
  -pwd "YourStrongPassword"

Then export the CSR from the wallet:

orapki wallet export -wallet /etc/oracle/wallet \
  -dn "CN=www.yourdomain.com, O=Your Company LLC, L=Seattle, ST=Washington, C=US" \
  -request /tmp/yourdomain.csr \
  -pwd "YourStrongPassword"

Replace the wallet path, DN, and password with your own values. The DN on the export command must match the DN you used when adding the key pair. The -addext_san flag (orapki 12.2.1.1 and later) embeds the Subject Alternative Names directly in the CSR; list every hostname the certificate must cover, including both the apex and the www subdomain. The file yourdomain.csr now contains the CSR, ready to submit.

Submit the CSR

Open the .csr file in any text editor (for example, Notepad). The file is plain text, starting with —–BEGIN NEW CERTIFICATE REQUEST—– (or —–BEGIN CERTIFICATE REQUEST—–) and ending with the matching —–END line. Copy the entire block, including those header and footer lines, and paste it into the CSR field during checkout with your CA.

Generate a CSR on Oracle iPlanet Web Server

Oracle iPlanet (formerly Sun Java System Web Server, then Sun ONE) keeps server certificates and their keys in a token store. The CSR wizard lives in the admin console:

1. In the Oracle iPlanet admin console, open Server Certificates and click Request.
2. From the Configuration list, pick the configuration the certificate is for.
3. Select the Token (Cryptographic Device) that will hold the key. If the key is stored on the server, choose Internal; otherwise pick your external token from the drop-down. Enter the password for the selected token.
4. Fill in the certificate details:
   • Server Name: the fully qualified domain name you want to secure, for example www.yourdomain.com. For a wildcard certificate, prefix with an asterisk, for example *.yourdomain.com.
   • Organization (O): your full legal company name, for example Your Company LLC.
   • Organizational Unit (OU): deprecated by public CAs. Leave blank.
   • Locality (L): the full city name where your organization is registered.
   • State or Province (ST): the full state name where your organization is registered.
   • Country (C): the two-letter ISO country code, for example US for the United States. See the full list of country codes.
5. For Key Type, select RSA with 2048 bits (or larger).
6. For the Certificate Signing Authority (CSA), select CA Signed.
7. Review the values you entered, then click Generate Request, then Finish.
8. Copy the newly generated CSR (including the —–BEGIN NEW CERTIFICATE REQUEST—– and —–END NEW CERTIFICATE REQUEST—– lines) into a text file, then click Close.

Note: like Oracle Wallet Manager, the iPlanet CSR wizard does not expose a SAN field. Provide every hostname the certificate must cover (apex plus www, plus any other subdomains) in the SAN field on your CA’s order form.

Generate a CSR on Oracle WebLogic Server

Oracle WebLogic Server uses Java keystores. You generate the CSR with the Java keytool utility in two commands: first keytool -genkeypair creates the keystore and the private key under a chosen alias, then keytool -certreq exports the matching CSR. The same alias must be reused later when you import the signed certificate, so the key, the CSR, and the eventual certificate all live in one place.

Step 1: Create the keystore and the private key

Open a terminal on the WebLogic server and create a new keystore in PKCS12 format. PKCS12 is the default keystore format in Java since JDK 9 and is the modern, portable standard. The older proprietary JKS format is officially deprecated:

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

What the flags mean:

• -alias server: the entry name inside the keystore. Pick a label you will recognize (often 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.
• -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 with something you will remember, and keep the 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.

Note: if you must keep using JKS for an older WebLogic deployment, swap -storetype PKCS12 for -storetype JKS and use a .jks extension. The rest of the workflow is identical. For wildcard certificates, do not use an asterisk in the keystore filename: that character is not supported on most filesystems.

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 WebLogic’s keystore configuration. 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, as 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): no longer issued by public CAs. Leave blank by pressing Enter.
• Organization (O): the full legal name of your company, for example Your Company LLC. If your company name contains symbols such as & or @, spell them out or omit them; keytool will reject some special characters.
• City or locality (L): the full city name, for example San Francisco. 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 Francisco, 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 server \
  -keyalg RSA -keysize 2048 \
  -storetype PKCS12 \
  -keystore yourdomain.p12 \
  -dname "CN=www.yourdomain.com, O=Your Company LLC, L=San Francisco, 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 server \
  -keystore yourdomain.p12 \
  -file yourdomain.csr \
  -ext san=dns:yourdomain.com,dns:www.yourdomain.com

What the flags mean:

• -alias server: 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 WebLogic 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 WebLogic’s SSL listener will not start. 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, server).
• 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:

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 NEW CERTIFICATE REQUEST—– and ending with —–END NEW 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 (yourdomain.p12) to a safe location before you close the terminal. If you lose the keystore, you lose the private key, and the certificate the CA issues will be useless.

After the CA validates your request and issues the certificate, continue with how to install your SSL certificate on Oracle. On WebLogic, you import the signed certificate back into the same alias in the same keystore, and then point the SSL listener at that keystore.