JKS Keystore
JKS Keystore manages a Java KeyStore file on disk and provides operations for listing, generating, importing, exporting, and deleting certificates and key pairs.
Store certificates for TLS and integration trust
Use JKS Keystore when the agent needs managed certificate material for local TLS endpoints, client certificates, private CA workflows, mutual TLS, or integration-specific trust chains.
The component can create a keystore file, load an existing one, generate self-signed certificates, generate certificates signed by another CA keystore, import external certificates, and export certificates or key pairs.
Choose storage location
Set Path to a protected directory and File name to a meaningful keystore file name. The JKS extension is added automatically when needed.
Set strong passwords
Set Keystore Password to a strong value before production use. Do not keep production keystores on the default password.
Connect CA only when needed
Use CA Keystore, CA Alias, and CA password only when generated certificates should be signed by a local CA key.
Configuration parameters
| Parameter | Required | Description | Default |
|---|---|---|---|
File storage provider | Hidden | File system reference used by the folder chooser. It defaults to the server-local file system. | Server local file system |
Title | Yes | Display name of this keystore role. | None |
Path | Yes | Directory where the keystore file is stored. | None |
File name | Yes | Keystore file name. The .jks extension is appended automatically when needed. | None |
Keystore Password | Optional | Password used to load and save the keystore file. Replace the default value before production use. | changeit |
Create if Missing | Optional | Creates an empty keystore file if the configured file is missing. Disable it when an existing file must be present. | Enabled |
CA Keystore | Optional | Optional keystore containing a CA private key used to sign generated certificates. | None |
CA Alias | Conditional | Alias of the CA key pair in the selected CA keystore. Visible when a CA keystore is selected. | None |
CA password | Conditional | Password for the selected CA private key. Visible when a CA keystore and CA alias are selected. | None |
Manage certificates and key pairs in one file
The keystore file is loaded when the component starts. Operations can list aliases, inspect certificate details, generate self-signed certificates, generate CA-signed certificates, import external material, export certificates, or delete entries.
Alias names are unique inside one keystore. Generated certificates refuse to overwrite an existing alias, so choose aliases intentionally and keep backups before destructive changes.
Server certificates
Generate or import certificates for local TLS endpoints and browser-accessed services.
Local CA
Use one keystore as a private CA and sign leaf certificates in another keystore.
Inventory
Review aliases, subjects, issuers, validity, usage, SAN values, and fingerprints before connecting services.
Use keystores for certificate storage and signing
Keystore roles
Local certificate storage
Create a dedicated keystore per integration domain, for example one for local TLS endpoints and another for client certificates. Keep the directory protected.
Existing keystore management
Set Path, File name, and Keystore Password to an existing file, then disable Create if Missing to avoid creating an empty keystore because of a typo.
Certificate generation and signing
Self-signed server certificate
Generate a server certificate and include all hostnames and IP addresses used by clients in subject alternative names. Explicit SAN values are safer for modern TLS clients.
Local CA keystore
Create a separate keystore with a CA certificate and keep its private key protected. Use it as CA Keystore for other keystores that need locally signed certificates.
CA-signed leaf certificates
Select CA Keystore, CA Alias, and CA password so generated leaf certificates are signed by the selected CA key instead of being self-signed.
Import, export, and audit
Import certificates
Use PEM or DER for public X.509 certificates, and PKCS12/JKS when importing a private key with its certificate chain.
Export for external consumers
Export PEM for certificate chains, DER for a single binary certificate, and PKCS12 when a private key must be transferred with the certificate.
Renewal workflow
Generate or import the new certificate under a new alias, test the dependent service, and delete the old alias only after the new certificate is active.
Operational notes
Do not use default passwords in production
Use strong different passwords for the keystore, exported PKCS12 files, and CA private keys when possible.
Back up before destructive changes
Keep backups before deleting aliases, changing passwords, or importing a new chain. Deleting an alias removes the key or certificate entry from the file.
Choose algorithms intentionally
Use RSA 2048/3072 or EC 256/384 for most deployments unless an integration requires a specific algorithm or key size.
CA-signed validity is fixed
For CA-signed generated certificates, the current implementation uses a fixed validity window of about 825 days. Use an external CA workflow for precise validity periods.
Protect private key export
PKCS12 export of a key pair includes the private key. Restrict read/update/delete permissions for this component.
Path and password changes restart
Changes to path, file name, password, CA keystore, or CA alias restart the component and reload the keystore file.