Post cover image

July 25, 2026

Day 204 — How to Renew an Application Certificate and Create a Java JKS Truststore

22nd July 2026, Netherlands — Certificates are commonly used to secure communication between applications, APIs, databases, message…

By Alok Rahul

13 min read

22nd July 2026, Netherlands — Certificates are commonly used to secure communication between applications, APIs, databases, message brokers, and external services. They allow systems to communicate over HTTPS or TLS without exposing sensitive data such as passwords, tokens, and customer information.

However, certificates do not remain valid forever. Every certificate has an expiration date. When an application certificate expires, users or dependent systems may see errors such as:

SSL certificate expired
PKIX path building failed
CertificateUnknown
SSLHandshakeException
unable to find valid certification path

To prevent outages, platform engineers must renew certificates before they expire and ensure that applications trust the new certificate chain.

This blog explains how to:

  1. Inspect the current certificate
  2. Back up the existing certificate files
  3. Generate a new private key and CSR using OpenSSL
  4. Generate a CSR using Java keytool
  5. Submit the CSR to a Certificate Authority
  6. Validate the issued certificate
  7. Create a Java JKS truststore
  8. Create a Java JKS keystore when the application also needs a private key
  9. Verify and deploy the renewed certificate safely

1. Understand the Certificate Components

Before running commands, it is important to understand the files involved.

Private key

The private key proves the identity of the application or server.

Example:

app-server.key

The private key must remain secret. Anyone who obtains it may be able to impersonate your application.

Certificate Signing Request

A Certificate Signing Request, or CSR, contains the application's public key and identity information.

Example:

app-server.csr

The CSR is sent to a Certificate Authority. It does not contain the private key.

Signed certificate

The Certificate Authority validates the request and issues a signed certificate.

Example:

app-server.crt

This certificate is presented by the application during a TLS connection.

Root and intermediate certificates

A server certificate is normally signed by an intermediate Certificate Authority, which is trusted through a root Certificate Authority.

The chain often looks like this:

Application certificate
        |
Intermediate CA certificate
        |
Root CA certificate

A client must trust this chain to accept the application certificate.

Keystore and truststore

A keystore usually contains:

  • The application certificate
  • The private key
  • Intermediate certificates

A truststore usually contains:

  • Root CA certificates
  • Intermediate CA certificates
  • Certificates of systems that the application trusts

A simple way to remember the difference is:

Keystore   = Who am I?
Truststore = Whom do I trust?

2. Inspect the Existing Certificate

Before renewing a certificate, inspect the current certificate to understand its subject, issuer, expiration date, and Subject Alternative Names.

For a local certificate file, run:

openssl x509 \
  -in app-server.crt \
  -noout \
  -subject \
  -issuer \
  -dates \
  -serial \
  -ext subjectAltName

Example output:

subject=CN=api.example.com,O=Example Ltd,C=IN
issuer=CN=Example Internal CA,O=Example Ltd,C=IN
notBefore=Jul 15 00:00:00 2025 GMT
notAfter=Jul 15 23:59:59 2026 GMT
X509v3 Subject Alternative Name:
    DNS:api.example.com, DNS:api.internal.example.com

Why this step is important

The renewed certificate should normally preserve the correct identity details of the existing certificate.

In particular, verify:

  • Common Name
  • Subject Alternative Names
  • Organization
  • Certificate issuer
  • Key algorithm
  • Expiration date

Modern TLS clients validate hostnames primarily through the Subject Alternative Name extension. A certificate with the correct Common Name but missing the required SAN may still fail hostname validation.

You can also inspect a live server certificate:

openssl s_client \
  -connect api.example.com:443 \
  -servername api.example.com \
  </dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -dates -ext subjectAltName

The -servername option sends the Server Name Indication value. This is important when multiple HTTPS applications share the same IP address.

3. Back Up the Existing Certificate Material

Before replacing anything, create a backup.

mkdir -p /opt/cert-backup/$(date +%Y%m%d)
cp app-server.crt \
   app-server.key \
   truststore.jks \
   /opt/cert-backup/$(date +%Y%m%d)/

If a keystore is being used, back it up as well:

cp application.jks \
   /opt/cert-backup/$(date +%Y%m%d)/

Why this step is important

Certificate deployment can fail because of:

  • An incorrect certificate chain
  • A mismatched private key
  • A wrong password
  • File-permission problems
  • An incorrect alias
  • An application configuration error

A backup provides a rollback path. Without one, restoring the service during an outage may become difficult.

Private keys and keystores should be protected carefully:

chmod 600 app-server.key
chmod 600 application.jks
chmod 600 truststore.jks

Method 1: Generate the Private Key and CSR Using OpenSSL

OpenSSL is commonly used for applications such as Nginx, Apache HTTP Server, HAProxy, Kafka, databases, and many non-Java workloads.

4. Generate a New Private Key

Generate a 3072-bit RSA private key:

openssl genpkey \
  -algorithm RSA \
  -out app-server.key \
  -pkeyopt rsa_keygen_bits:3072

Protect the file:

chmod 600 app-server.key

Verify the key:

openssl pkey \
  -in app-server.key \
  -check \
  -noout

Expected output:

Key is valid

Why a private key is required

The private key is used by the server during the TLS handshake to prove that it owns the certificate.

The Certificate Authority signs the public key contained in the CSR, but the private key remains on your server.

The private key must never be sent to the Certificate Authority.

Should the old key be reused?

Some organizations reuse the existing private key during renewal. Others require key rotation.

Generating a new key is generally safer because it:

  • Reduces the risk associated with long-lived keys
  • Limits exposure if an older key was compromised
  • Meets many security and compliance policies

However, confirm the organization's certificate policy before rotating the key.

5. Create an OpenSSL Configuration File

Create a file called csr.conf:

[ req ]
default_bits       = 3072
prompt             = no
default_md         = sha256
distinguished_name = subject
req_extensions     = request_extensions
[ subject ]
C  = IN
ST = Karnataka
L  = Bengaluru
O  = Example Ltd
OU = Platform Engineering
CN = api.example.com
[ request_extensions ]
subjectAltName = @alternative_names
keyUsage = critical, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
[ alternative_names ]
DNS.1 = api.example.com
DNS.2 = api.internal.example.com

Why use a configuration file?

A configuration file makes the request repeatable and reduces typing mistakes.

It is especially useful for Subject Alternative Names. Entering SAN values interactively is inconvenient and easy to get wrong.

The most important fields are:

  • CN: The primary hostname
  • DNS.1, DNS.2: Additional valid hostnames
  • keyUsage: Permitted cryptographic use
  • extendedKeyUsage: Indicates whether the certificate is for server or client authentication

For a server certificate, serverAuth is normally required.

For mutual TLS client authentication, the Certificate Authority may require:

extendedKeyUsage = clientAuth

Or both:

extendedKeyUsage = serverAuth, clientAuth

6. Generate the CSR with OpenSSL

Run:

openssl req \
  -new \
  -key app-server.key \
  -out app-server.csr \
  -config csr.conf

Inspect the CSR:

openssl req \
  -in app-server.csr \
  -noout \
  -text \
  -verify

You can display only the subject and SAN values:

openssl req \
  -in app-server.csr \
  -noout \
  -subject
openssl req \
  -in app-server.csr \
  -noout \
  -text |
grep -A1 "Subject Alternative Name"

Why validate the CSR?

The Certificate Authority creates the certificate based on the CSR.

If the CSR contains:

  • The wrong hostname
  • A missing SAN
  • The wrong organization
  • An incorrect key usage

the issued certificate may not work, and a new request may be required.

Validating the CSR before submission avoids unnecessary delays.

Method 2: Generate the CSR Using Java Keytool

Java applications often use Java KeyStore files. The keytool utility is included with the Java Development Kit and many Java Runtime Environment installations.

7. Generate a Key Pair in a JKS Keystore

Run:

keytool -genkeypair \
  -alias application-server \
  -keyalg RSA \
  -keysize 3072 \
  -sigalg SHA256withRSA \
  -validity 825 \
  -keystore application.jks \
  -storetype JKS \
  -storepass changeit \
  -keypass changeit \
  -dname "CN=api.example.com, OU=Platform Engineering, O=Example Ltd, L=Bengaluru, ST=Karnataka, C=IN" \
  -ext "SAN=dns:api.example.com,dns:api.internal.example.com" \
  -ext "KU=digitalSignature,keyEncipherment" \
  -ext "EKU=serverAuth"

What this command creates

The command creates:

  • A private key
  • A public key
  • A temporary self-signed certificate
  • A JKS keystore containing the key entry

The self-signed certificate is only a placeholder. It will later be replaced with the certificate signed by the Certificate Authority.

Why specify an alias?

A Java keystore can contain multiple entries. The alias identifies a particular key or certificate.

For example:

application-server
root-ca
intermediate-ca

The same alias used to create the private key must be used when importing the signed certificate. Otherwise, Java may create a separate trusted certificate entry instead of attaching the signed certificate to the private key.

Why specify SAN explicitly?

Java does not automatically treat the Common Name as a complete replacement for SAN.

The SAN list must contain every hostname clients will use to access the application.

For example, if users connect using both:

api.example.com
api.internal.example.com

both names must appear in the SAN extension.

8. Generate the CSR from the JKS Keystore

Run:

keytool -certreq \
  -alias application-server \
  -keystore application.jks \
  -storepass changeit \
  -keypass changeit \
  -file application-server.csr \
  -ext "SAN=dns:api.example.com,dns:api.internal.example.com" \
  -ext "KU=digitalSignature,keyEncipherment" \
  -ext "EKU=serverAuth"

Inspect the CSR:

keytool -printcertreq \
  -file application-server.csr \
  -v

Why generate the CSR from the same keystore?

The CSR must use the public key corresponding to the private key that will remain in the keystore.

When the Certificate Authority returns the signed certificate, Java matches it to the existing private key through the alias.

If the CSR is generated from a different private key, the certificate cannot be used with the original keystore key entry.

9. Submit the CSR to the Certificate Authority

The CSR can be submitted to:

  • An internal enterprise CA
  • Microsoft Active Directory Certificate Services
  • HashiCorp Vault PKI
  • A cloud certificate service
  • A public Certificate Authority
  • An organizational security team

Display the CSR in PEM format:

cat app-server.csr

It will look similar to:

-----BEGIN CERTIFICATE REQUEST-----
MIID...
-----END CERTIFICATE REQUEST-----

Send only the CSR.

Do not send:

app-server.key
application.jks

Why does the CA need the CSR?

The CA uses the CSR to:

  • Read the requested public key
  • Validate the requested identity
  • Apply certificate policy
  • Sign the certificate
  • Establish a chain of trust

The private key is not required by the CA because certificate signing only requires the public key and identity details.

10. Receive the Signed Certificates

The Certificate Authority may return files such as:

application-server.crt
intermediate-ca.crt
root-ca.crt

Sometimes the CA provides a bundle:

ca-chain.crt

The application certificate is the leaf certificate. The intermediate and root certificates establish trust back to the issuing authority.

Check the certificate:

openssl x509 \
  -in application-server.crt \
  -noout \
  -subject \
  -issuer \
  -dates \
  -serial \
  -ext subjectAltName

Why inspect the issued certificate?

A CSR may be correct, but the CA can modify or reject requested extensions according to policy.

Confirm that the issued certificate contains:

  • The correct subject
  • The correct SAN entries
  • The expected issuer
  • The correct validity period
  • The appropriate key usage

11. Verify That the Certificate Matches the Private Key

For RSA keys, compare the public-key fingerprints.

openssl pkey \
  -in app-server.key \
  -pubout \
  -outform pem |
sha256sum
openssl x509 \
  -in application-server.crt \
  -pubkey \
  -noout |
sha256sum

The hashes must match.

Why this check matters

A certificate is usable only with the private key associated with its public key.

If the hashes differ, the certificate was issued for another private key. The TLS service may fail to start or may report a key mismatch.

This usually happens when:

  • The wrong CSR was submitted
  • The wrong private key was selected
  • Certificate files from different environments were mixed
  • The key was regenerated after creating the CSR

12. Verify the Certificate Chain

Create a CA bundle:

cat intermediate-ca.crt root-ca.crt > ca-chain.crt

Verify the server certificate:

openssl verify \
  -CAfile ca-chain.crt \
  application-server.crt

Expected output:

application-server.crt: OK

Why verify the chain?

A valid application certificate must lead back to a trusted root CA.

If an intermediate certificate is missing, clients may reject the certificate even though the application certificate itself has not expired.

The chain should normally be ordered like this when presented by a server:

Application certificate
Intermediate CA certificate
Additional intermediate certificates, if any

The root certificate is usually stored in the client's truststore rather than sent by the server.

Creating a JKS Truststore

13. Create an Empty JKS Truststore

A Java truststore is usually created by importing the required CA certificates.

Import the root CA:

keytool -importcert \
  -alias example-root-ca \
  -file root-ca.crt \
  -keystore truststore.jks \
  -storetype JKS \
  -storepass changeit \
  -noprompt

Import the intermediate CA:

keytool -importcert \
  -alias example-intermediate-ca \
  -file intermediate-ca.crt \
  -keystore truststore.jks \
  -storetype JKS \
  -storepass changeit \
  -noprompt

Why import the CA certificates?

A truststore should normally trust the issuing Certificate Authority rather than only one specific application certificate.

When the root and intermediate CA certificates are trusted, Java can validate any permitted certificate issued through that chain.

This also makes future certificate renewal easier. If the renewed application certificate is issued by the same CA chain, the truststore may not require an update.

Should the application certificate be imported?

In some environments, administrators import the application certificate directly:

keytool -importcert \
  -alias application-server \
  -file application-server.crt \
  -keystore truststore.jks \
  -storetype JKS \
  -storepass changeit \
  -noprompt

This is known as direct certificate trust or certificate pinning.

It is more restrictive, but it creates additional maintenance because the truststore must be updated whenever the application certificate changes.

For most internal PKI environments, importing the trusted CA chain is more scalable.

14. Verify the JKS Truststore

List its contents:

keytool -list \
  -v \
  -keystore truststore.jks \
  -storepass changeit

Look for:

Alias name: example-root-ca
Entry type: trustedCertEntry

and:

Alias name: example-intermediate-ca
Entry type: trustedCertEntry

Why verify the aliases and entry types?

A truststore entry should usually appear as:

trustedCertEntry

This indicates that Java trusts the imported certificate.

Verification also confirms that:

  • The correct certificate was imported
  • The alias is unique
  • The expiration date is valid
  • The truststore password works
  • The keystore format is correct

Importing the Signed Certificate into a Keytool-Generated Keystore

If the CSR was created using keytool, the signed certificate must be imported back into the same keystore.

The import order matters.

15. Import the Root Certificate

keytool -importcert \
  -trustcacerts \
  -alias example-root-ca \
  -file root-ca.crt \
  -keystore application.jks \
  -storepass changeit \
  -noprompt

16. Import the Intermediate Certificate

keytool -importcert \
  -trustcacerts \
  -alias example-intermediate-ca \
  -file intermediate-ca.crt \
  -keystore application.jks \
  -storepass changeit \
  -noprompt

17. Import the Application Certificate

keytool -importcert \
  -alias application-server \
  -file application-server.crt \
  -keystore application.jks \
  -storepass changeit

Why must the CA certificates be imported first?

Java needs to build a complete certificate chain when importing the application certificate.

If the root and intermediate certificates are not known, keytool may report:

Failed to establish chain from reply

Importing the CA certificates first gives Java the trust information needed to connect the application certificate to its issuer.

Why use the original application alias?

The signed certificate must replace the temporary self-signed certificate connected to the private key.

Using another alias may create only a trusted certificate entry, leaving the private key entry unchanged.

18. Verify the Keystore Entry

Run:

keytool -list \
  -v \
  -alias application-server \
  -keystore application.jks \
  -storepass changeit

Look for:

Entry type: PrivateKeyEntry
Certificate chain length: 3

A chain length of three normally represents:

Application certificate
Intermediate CA
Root CA

Why is PrivateKeyEntry important?

A server-side Java application needs access to both:

  • The certificate
  • The corresponding private key

A trustedCertEntry contains only a certificate. It cannot be used by the application to prove its own identity.

A PrivateKeyEntry confirms that the keystore contains the private key and its certificate chain.

Creating a JKS Keystore from OpenSSL Files

If the private key and certificate were generated using OpenSSL, they cannot usually be imported directly into JKS as separate files.

The common approach is:

PEM files
   ↓
PKCS#12 keystore
   ↓
JKS keystore

19. Create the Certificate Chain File

cat intermediate-ca.crt root-ca.crt > ca-chain.crt

20. Create a PKCS#12 Keystore

openssl pkcs12 \
  -export \
  -name application-server \
  -inkey app-server.key \
  -in application-server.crt \
  -certfile ca-chain.crt \
  -out application.p12

OpenSSL will ask for an export password.

Why use PKCS#12?

PKCS#12 can store:

  • A private key
  • A signed certificate
  • The full certificate chain

Java can import this combined structure into a JKS keystore.

A plain .crt file does not contain the private key, and a plain .key file does not contain the certificate chain. PKCS#12 packages all required components together.

21. Convert PKCS#12 to JKS

keytool -importkeystore \
  -srckeystore application.p12 \
  -srcstoretype PKCS12 \
  -srcstorepass changeit \
  -destkeystore application.jks \
  -deststoretype JKS \
  -deststorepass changeit \
  -destkeypass changeit \
  -alias application-server

Verify:

keytool -list \
  -v \
  -keystore application.jks \
  -storepass changeit

Confirm that the entry type is:

PrivateKeyEntry

JKS versus PKCS#12

Modern Java versions support PKCS#12 directly, and PKCS#12 is often preferred because it is an industry-standard format.

However, some legacy Java applications or organizational standards still require JKS.

Check the application documentation before converting.

Deploying the Renewed Certificate

22. Update the Application Configuration

A Java application may use properties similar to:

server.ssl.key-store=/opt/application/application.jks
server.ssl.key-store-password=${KEYSTORE_PASSWORD}
server.ssl.key-store-type=JKS
server.ssl.key-alias=application-server
server.ssl.trust-store=/opt/application/truststore.jks
server.ssl.trust-store-password=${TRUSTSTORE_PASSWORD}
server.ssl.trust-store-type=JKS

JVM-level truststore options may look like:

-Djavax.net.ssl.trustStore=/opt/application/truststore.jks
-Djavax.net.ssl.trustStorePassword=changeit
-Djavax.net.ssl.trustStoreType=JKS

Why should passwords not be hard-coded?

Keystore and truststore passwords should not be stored directly in:

  • Source code
  • Git repositories
  • Public configuration files
  • Dockerfiles
  • Shell history

Use a secret manager, encrypted configuration, Kubernetes Secret, or protected environment variable.

23. Restart or Reload the Application

Some applications load certificate files only during startup.

For a systemd service:

sudo systemctl restart application

Check the service:

sudo systemctl status application

Review logs:

sudo journalctl \
  -u application \
  -n 100 \
  --no-pager

Why is a restart sometimes required?

The application may keep the private key and certificate in memory.

Replacing the files on disk does not necessarily update the in-memory TLS configuration. A restart or supported TLS reload forces the application to load the renewed certificate.

Always verify whether the product supports live certificate reload before restarting a production workload.

24. Validate the Deployed Certificate

Test the live endpoint:

openssl s_client \
  -connect api.example.com:443 \
  -servername api.example.com \
  -showcerts

Check only the certificate dates:

openssl s_client \
  -connect api.example.com:443 \
  -servername api.example.com \
  </dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -dates

Test with curl:

curl -v https://api.example.com

When using a private CA:

curl \
  --cacert root-ca.crt \
  https://api.example.com

Why test from the client side?

An application may start successfully while still presenting:

  • The old certificate
  • An incomplete certificate chain
  • A certificate for the wrong hostname
  • A certificate from the wrong load balancer
  • A certificate that clients do not trust

Testing through the actual endpoint validates the complete client-to-server path.

Common Errors and Their Causes

Failed to establish chain from reply

Cause:

  • The root or intermediate CA certificate is missing
  • Certificates were imported in the wrong order
  • The CA returned the wrong chain

Resolution:

Import the root and intermediate certificates before importing the signed application certificate.

Certificate reply does not contain public key

Cause:

The signed certificate does not match the private key associated with the alias.

Resolution:

Confirm that the correct CSR was submitted and that the certificate belongs to the same private key.

PKIX path building failed

Cause:

The client truststore does not contain a trusted path to the certificate issuer.

Resolution:

Import the required root and intermediate CA certificates into the client truststore.

No subject alternative names present

Cause:

The certificate does not contain the hostname in the SAN extension.

Resolution:

Create a new CSR containing the required SAN values and request a new certificate.

Keystore was tampered with, or password was incorrect

Cause:

  • Incorrect keystore password
  • Incorrect key password
  • Damaged keystore
  • Wrong keystore format

Resolution:

Confirm the password and inspect the store type:

keytool -list \
  -keystore application.jks \
  -storepass changeit

Before certificate renewal:

  • Check the existing certificate expiration date
  • Identify all required hostnames
  • Confirm whether the private key must be rotated
  • Back up the current keystore and certificate files
  • Confirm the required keystore format
  • Record current file ownership and permissions

During renewal:

  • Generate a secure private key
  • Create the CSR with all required SAN entrie
  • Validate the CSR before submission
  • Submit only the CSR to the CA
  • Verify the returned certificate
  • Confirm that the certificate matches the private key
  • Validate the full certificate chain

After renewal:

  • Import the CA chain and application certificate correctly
  • Verify PrivateKeyEntry for server keystores
  • Verify trustedCertEntry for truststores
  • Deploy using secure file permissions
  • Restart or reload the application
  • Test the certificate from a client
  • Monitor application logs
  • Keep the backup until the new certificate is confirmed stable

Conclusion

Renewing an application certificate is more than replacing an expired .crt file. A successful renewal requires the private key, CSR, signed certificate, certificate chain, keystore, and truststore to work together.

OpenSSL is commonly used when certificates and private keys are managed as PEM files. Java keytool is useful when the application expects certificates and private keys inside a Java keystore.

The most important concepts are:

Private key = Secret identity proof
CSR         = Request containing the public key
Certificate = CA-signed application identity
Keystore    = Application identity and private key
Truststore  = Certificates and CAs the application trusts

Understanding why each component exists makes certificate renewal easier to troubleshoot, safer to automate, and less likely to cause production outages.