Replace all installer-generated certificate material with your own public CA or enterprise PKI material.
Overview
When replacing all certificate material, the recommended strategy is
-
Generate a baseline certificate structure from the installer on
backend-1. -
Deploy the generated structure and
.envfiles to all other nodes. -
Replace the installer-generated CA with BYOC CA chain in place.
-
Generate BYOC materials.
-
Review requirements for each certificate type.
-
Ensure BYOC material names match installer-generated materials.
-
If applicable, create combo .PEMs (Certificate → Intermediates (if applicable) → Key).
-
-
Replace the installer generated certificates and keys with BYOC materials in place.
-
Use the same filenames and directories as installer-generated material on all nodes.
-
-
Set replacement certificate and key file permissions to
400(read-only for owner) after replacing.
Note on Enterprise PKI issuance methods:
You are responsible for obtaining the certificate material in the filenames and formats required by AgileSec as defined in the following sections. Generally, required files include a certificate, private key, and any intermediate chain in PEM format.
Depending on your PKI, you may either (a) generate a CSR and have the PKI sign it, or (b) request a certificate where the PKI generates and returns a keypair (often as a PKCS#12/PFX bundle). AgileSec supports both approaches, as long as you can provide the resulting materials as PEM files with the required filenames. If your PKI returns a PKCS#12/PFX bundle, extracting it into separate PEM files is your responsibility.
Important: Protective Certificate and Key File Permissions
generate_certs.sh applies restrictive permissions to protect installer generated certificate and key files.
BYOC certificate and key files should only be readable by the owning user. Set replacement certificate and key file permissions to 400 (read-only for owner) after copying them into place.
Prerequisites
Ensure all BYOC: Prerequisites have been met, including correct variables in .env.
Important
Pre-Install BYOC: If .env does not align with BYOC certificates materials or models, update and regenerate .env or BYOC materials to align before proceeding.
Post-Install BYOC: It is not recommended to update configuration variables affecting BYOC post-installation. Align BYOC materials with the AgileSec installation’s current .env.
Set Environment Variable
-
Set variable
$installer_dironbackend-1to easily copy and paste guide instructions into terminal:export installer_dir=</path-to-installer-directory>
-
If performing post-install BYOC, also set the installation directory variable
$agilesec_installation_dir:$agilesec_installation_dir=</path-to-agilesec-installation>
Step 1 (Pre-Install BYOC Only): Prepare Baseline Certificate Structure
When performing pre-install BYOC, follow these instructions for preparing the baseline certificate structure. This step does not need to be repeated for post-install BYOC.
-
Generate baseline certificate directory structure.
-
Deploy baseline certificate structure and
.envfiles to all nodes.
Generate Baseline Certificate Structure
Installer-generated certificate materials and directory structure can be created with generate_certs.sh. Use the same filenames and directory structure as the installer generates for any BYOC materials.
On backend-1 or single-node, run generate-certs.sh to generate and self-sign all required certificates:
cd $installer_dir/certificates/
./generate-certs.sh
cd ..
generate-certs.sh populates all required certificate files under the certificates directory and generates an archive file named kf-agilesec.internal-certs.tgz. kf-agilesec.internal-certs.tgz contains all generated certificate files as well as each node’s .env. After generation, kf-agilesec.internal-certs.tgz must be copied from backend-1 to all other nodes.
The script has the following additional option flags available. Installation options can also be found by running ./generate-certs.sh --help.
|
generate-certificates.sh short flag |
Required |
Description |
|---|---|---|
|
|
No |
Non-interactive mode: no prompts, overwrite files. |
|
|
No |
Path to .env file. Defaults to |
|
|
No |
Verbose mode: outputs additional console statements for debugging. |
|
|
No |
Validation-only mode: validates existing certificates in specified directory. |
Info: By default, generate_certs.sh uses a self-signed installer-generated CA to sign all certificates.
Deploy Generated Files to All Nodes
Copy kf-agilesec.internal-certs.tgz from backend-1 to all other nodes.
For each node, copy kf-agilesec.internal-certs.tgz to $installer_dir/certificates/.
4-Node Cluster Example
scp kf-agilesec.internal-certs.tgz <user@frontend-1 IP>:$installer_dir/certificates/
scp kf-agilesec.internal-certs.tgz <user@frontend-2 IP>:$installer_dir/certificates/
scp kf-agilesec.internal-certs.tgz <user@backend-2 IP>:$installer_dir/certificates/
Note: scp command is provided as an example. You may use any file transfer method suitable to your environment.
On each node, unarchive kf-agilesec.internal-certs.tgz to create the certificate structure:
cd $installer_dir/certificates/
tar zxvf kf-agilesec.internal-certs.tgz
Note: kf-agilesec.internal-certs.tgz also contains each node’s .env.
Step 2: Replace Root CA Certificate Chain
When BYOC, users must update the Root CA certificate chain of trust. For production deployments, your organization’s internal CA (enterprise PKI) and/or a publicly trusted CA may be used.
The Root CA certificate chain establishes the trust anchor for all internal TLS and mTLS communication within the AgileSec Platform. Platform services validate peer certificates (and client certificates for mTLS) against this CA chain. In multi-node deployments, the same CA chain must be trusted consistently across all nodes to prevent service-to-service authentication failures.
Warning: For a BYOC deployment, your organization retains full control of your CA private key at all times. Keyfactor never requests, receives, or has access to your CA's private key. You are responsible for generating and signing all BYOC certificates (Root CA, intermediate, server, and client certificates) using your own PKI infrastructure or tooling.
The steps below describe only where to place the resulting certificate files on AgileSec nodes, NOT how to generate or sign them.
Note: If you are using a public CA, download the Root CA certificate (and any required intermediate certificates) from the public CA's official distribution page. If you are using an enterprise/internal CA, obtain these files from your organization's PKI team or CA management system. Use those PEM files in the steps below.
CA Requirements
Ensure the BYOC CA meets the following requirements:
|
Requirements |
Details |
|
|---|---|---|
|
1 |
Root CA Filename
|
Must contain the Root CA and any intermediate certificates. Concatenate most-specific to least-specific: Intermediate(s) → Root CA cert. |
|
2 |
Certificate chain |
Ensure all internal server and client certificates used by the platform chain back to the trusted CA chain. Warning: The installer's chain validation checks certificates against |
|
3 |
Protective Permissions |
Apply |
Replace CA Trust Chains
|
Placement |
Details |
|
|---|---|---|
|
1 |
BYOC Filename |
|
|
2 |
BYOC Materials Location |
Note for Post-Install BYOC: Place BYOC certificates materials in the install directory location instead of installer directory, |
|
3 |
Nodes |
All Nodes |
Step 3: External (User-Facing) Certificates
The external (user-facing) certificate secures HTTPS access to the AgileSec Platform for end users and API clients. By default, this certificate is presented by the frontend HAProxy, which terminates TLS for the platform’s external endpoint.
External Certificate Requirements
Generate External Server Certificates BYOC materials meeting the following requirements:
|
Requirement |
Detail |
|
|---|---|---|
|
1 |
Certificate Filename |
If signed by an intermediate CA, concatenate: Certificate → Intermediates. If your CA issues through one or more intermediates, concatenate them into the external certificate file: Leaf Certificate → Intermediates, in order. Warning: Do not add intermediates to the trust anchor file |
|
2 |
Private Key Filename |
|
|
3 |
Certificate Key Combo File |
Concatenate in the following order: certificate file (already including intermediates if applicable) → Key. Warning: Missing intermediates commonly cause client errors such as "unable to verify the first certificate." |
|
4 |
SAN |
|
|
5 |
CN |
May be set to the same FQDN for readability but is not relied on for validation. |
|
6 |
Protective Permissions |
Apply |
Recommended: Approach with Load Balancer
For production deployments, it is highly recommended to place an enterprise load balancer (or reverse proxy) in front of the platform HAProxy rather than replacing HAProxy entirely. This preserves the platform’s default ingress behavior while allowing centralized HA, TLS management, and enterprise controls.
TLS termination options for production environments
|
TLS Termination Option |
Description |
Approach |
|---|---|---|
|
Terminate TLS at the enterprise load balancer |
The load balancer presents the public/enterprise certificate to end users and forwards traffic to HAProxy. |
Replace the BYOC external certificate on the load balancer. If you do not want to re-encrypt traffic between the load-balancer and HAProxy, no further steps are required. Leave the installer-generated certificate on the nodes alone. |
|
Pass-through TLS to HAProxy |
The load balancer forwards encrypted traffic and HAProxy presents the public/enterprise certificate to end users. |
Install the BYOC external certificate on Frontend Nodes by replacing the installer-generated external certificate on all frontend nodes. |
Terminate TLS at the enterprise load balancer
For production deployments with TLS terminated at the enterprise load balancer, replace the external certificate on the load balancer with one issued by your enterprise PKI or a public CA (agilesec-analytics-server-combo-cert-key.pem). There is no need to replace installer-generated external certificates on the nodes.
Note: No further steps are required unless you want to re-encrypt traffic between the load balancer and HAProxy. If you want to re-encrypt traffic, you may do so. See your load balancer provider’s documentation for guidance. AWS example documentation is available here: https://repost.aws/questions/QUDFSStHDQSoGg-oBs53T9Eg/off-loading-and-re-encrypting-traffic-on-application-load-balancer
Pass-Through TLS to HAProxy
For production deployments with a load balancer set up with TLS Pass-through, replace the external certificate on all frontend nodes with one issued by your enterprise PKI or a public CA.
Deploy BYOC External Server Certificate materials to the following locations and nodes:
|
Requirement |
Details / Permissions |
|---|---|
|
BYOC Files |
|
|
BYOC Directory Location |
Note for Post-Install BYOC: Place BYOC certificates materials in the install directory location instead of installer directory, |
|
Nodes |
All frontend nodes |
Approach Without Load Balancer
If not using a load balancer, follow the same steps as Pass-through TLS to replace the External Certificate but only deploy to frontend-1. Without a load balancer, frontend-1 will be the single-point of failure.
Step 4: Internal Server Certificates
Internal server certificates secure intra-platform communication. Internal certificates are typically issued by an installer-generated CA for POCs/first-time installs, or by an enterprise PKI for production deployments requiring centralized issuance and rotation. The client verifies the service’s server certificate to establish an encrypted channel to an internal endpoint.
The following two models are supported for internal server certificates:
-
Wildcard Certificate (default): A wildcard certificate for
*.<analytics_internal_domain>is used across internal server endpoints. The main benefit of this model is simplicity: internal services can share the same certificate and key, and internal clients only need to trust a single CA chain. -
Single Certificate with SANs: A single certificate is used across all nodes with all required internal hostnames as DNS SANs (for example,
backend-1.<analytics_internal_domain>,backend-2.<analytics_internal_domain>,frontend-1.<analytics_internal_domain>,scan-1.<analytics_internal_domain>). This approach avoids wildcard usage while keeping certificate management centralized.
By default, installer-generated internal server certificates use the Wildcard Certificate model.
Internal Server Certificates Requirements
Generate Internal Server Certificates BYOC materials meeting the following requirements:
|
Internal Server Certificates Requirement |
Detail |
|
|---|---|---|
|
1 |
Certificate Filename |
If signed by an intermediate CA, concatenate: Certificate → Intermediates. |
|
2 |
Private Key Filename |
|
|
3 |
Certificate Key Combo File |
Concatenate in the following order: Certificate file (already including intermediates if applicable) → Key. Warning: Missing intermediates commonly cause client errors such as "unable to verify the first certificate." |
|
4 |
Subject (DN) |
Base fields must match Example: |
|
5 |
CN |
Can be set to a primary internal hostname for readability; not relied on for validation. |
|
6 |
SAN |
Include all internal hostnames as DNS SANs for clients to validate against. For wildcard certificates: For single certificate with SANS:
Info: Scan nodes are numbered and variable in count; coordinator is always singular |
|
7 |
Key Usage |
|
|
8 |
Extended Key Usage |
|
|
9 |
Key algorithm |
Minimum: RSA 2048 or ECDSA P-256 Recommended: RSA 2048 or ECDSA P-256 Alternatively: P-384 Warning – EC Key Format: If using an ECDSA key, it must be in PKCS#8 format (
Confirm the resulting key PEM file begins with |
|
10 |
Signature hash |
SHA-256 (Minimum), SHA-384, SHA-512 |
|
11 |
Trust Chain |
Must chain to a CA trusted by all connecting nodes/components. Install into system trust store and Java trust store where applicable |
|
12 |
Protective Permissions |
Apply |
Place BYOC Internal Server Certificates
Deploy BYOC Internal Server Certificate materials to the following locations and nodes:
|
Placement |
Details |
|---|---|
|
BYOC Files |
|
|
BYOC Materials Location |
Note for Post-Install BYOC: Place BYOC certificates materials in the install directory location instead of installer directory, |
|
Nodes |
All backend nodes
Coordinator node |
Note for Post-Install BYOC: OpenSearch maintains its own copy of the internal server certificate and key under its service directory. If replacing internal certificates after AgileSec installation, these copies must also be updated on backend and frontend nodes:
-
$agilesec_installation_dir/services/opensearch/config/certs/agilesec-internal-server-cert.pem -
$agilesec_installation_dir/services/opensearch/config/certs/agilesec-internal-server-key.pem
(For pre-install BYOC, these updates are not required.)
Step 5: mTLS Client Certificates
mTLS client certificates are used for mutual TLS (mTLS) authentication for inter-service communication.
Confirm Client Certificate Model
Inspect .env to confirm the client certificate model:
-
Model 1: Single Shared Client Certificate (installer default). If configuration variable
use_single_client_cert=true, use one client certificate shared by all services. -
Model 2: Per-Service Client Certificates. If configuration variable
use_single_client_cert=false, use separate client certificates per service.
mTLS Client Certificates Requirements
Generate mTLS Client Certificates BYOC materials meeting the following requirements:
|
mTLS Client Certificates Requirement |
Details |
|---|---|
|
Subject (DN) |
Base fields must match Reverse the field order, then join with slashes. Do not retype from memory; convert the existing value directly so no field is dropped or mistyped. Example: converts to →
|
|
CN |
Set to CN distinguishes individual client certs since the base subject fields are shared across all clients. |
|
Key Usage |
|
|
Extended Key Usage |
|
|
Key algorithm |
Minimum: RSA 2048 or ECDSA P-256 Recommended: RSA 2048 or ECDSA P-256 Alternatively: P-384 Warning – EC Key Format: If using an ECDSA key, it must be in PKCS#8 format (
Confirm the resulting key PEM file begins with |
|
Signature hash |
SHA-256 (Minimum), SHA-384, SHA-512 |
|
Trust Chain |
Must chain back to the Root CA being used. |
|
Protective Permissions |
Apply |
Ensure BYOC materials meet the following additional requirements for each model:
Place BYOC mTLS Certificates
Deploy BYOC materials to the following locations and nodes.
|
Placement |
Details |
|---|---|
|
BYOC Materials Location |
Note for Post-Install BYOC: Place BYOC certificates materials in the install directory location instead of installer directory, |
|
Nodes |
Model 1: Shared Client Certificate
Model 2: Per-Service Client Certificate Files
|
Model 2: Update OpenSearch Configuration
If utilizing model 2, per-service client certificate files, perform the following steps to update OpenSearch configuration.
Step 6: Admin Client Certificates
Admin client certificates are used for privileged, certificate-based authentication to internal infrastructure components requiring elevated access
In the AgileSec Platform, admin client certificates are used for administrative connections to MongoDB and OpenSearch. For example, admin client certificates perform secure administrative operations during installation, configuration, and troubleshooting.
Admin client certificates are always separate from service-to-service mTLS client certificates and must be treated as sensitive credentials.
Confirm Client Certificate Model
Inspect .env to confirm the client certificate model:
-
Model 1: Single Shared Client Certificate (installer default). If configuration variable
use_single_client_cert=true, a single admin client certificate is used for administrative authentication to both MongoDB and OpenSearch. -
Model 2: Per-Service Client Certificates. If configuration variable
use_single_client_cert=false, separate admin certificate assets are used for administrative authentication to MongoDB and OpenSearch.
Admin Client Certificates Requirements
Generate admin client certificates BYOC materials meeting the following requirements:
|
Requirement |
Details |
|
|---|---|---|
|
1 |
Subject (DN) |
Handle Subject DN carefully when replacing this certificate: DN is used as an identity value by OpenSearch and MongoDB.
For OpenSearch: Must exactly match For MongoDB: Mapped to an Both OpenSearch and MongoDB:
|
|
2 |
CN |
Single shared certificate:
Per-service client certificates:
|
|
3 |
Key Usage |
|
|
4 |
Extended Key Usage |
|
|
5 |
Key algorithm |
Minimum: RSA 2048 or ECDSA P-256 Recommended: RSA 2048 or ECDSA P-256 Alternatively: P-384 Warning – EC Key Format: If using an ECDSA key, it must be in PKCS#8 format (
Confirm the resulting key PEM file begins with |
|
6 |
Signature hash |
SHA-256 (Minimum), SHA-384, SHA-512 |
|
7 |
Trust Chain |
Must chain back to the Root CA being used. |
Ensure BYOC materials meet the following additional requirements for each model:
Place BYOC Admin Certificates
Deploy BYOC materials to the following locations and nodes.
|
Placement |
Details |
|---|---|
|
|
|
|
BYOC Materials Location |
Note for Post-Install BYOC: Place BYOC certificates materials in the install directory location instead of installer directory, |
|
Nodes |
All backend nodes
|
Step 7: SAML IdP Signing Certificate (WIP)
The AgileSec Platform includes a SAML Identity Provider (IdP) signing certificate used when the platform acts as the IdP for SSO integration for OpenSearch Dashboards. This certificate signs SAML assertions so the Service Provider (SP) can validate authenticity and integrity. This certificate is not used for TLS.
SAML IdP Signing Certificates Requirements
Generate BYOC materials meeting the following requirements.
|
Requirement |
Details |
|
|---|---|---|
|
1 |
IdP Certificate Filename |
|
|
2 |
IdP Encrypted Private Key Filename |
|
|
3 |
Private Key Password Filename |
|
|
4 |
Subject (DN) |
Can be set to any value (O, OU, ST, C, CN). |
|
5 |
CN |
Can be set to any value. |
|
6 |
Key Usage |
|
|
7 |
Extended Key Usage |
Not applicable; omit. This certificate is not used for TLS. |
|
8 |
Key algorithm |
Minimum and Recommended: RSA 2048 |
|
9 |
Signature hash |
SHA-256 (Minimum), SHA-384, SHA-512 |
|
10 |
Protective Permissions |
Apply |
Important: Treat idp-enc-key.pem and saml.pass as sensitive secrets. Restrict access and back them up securely.
idp-cert.pem is safe to distribute internally to Service Providers requiring SAML signatures validation.
Place BYOC SAML IdP Signing Certificates
Place BYOC materials in the following locations and nodes.
|
Placement |
Details |
|---|---|
|
Directory |
Note for Post-Install BYOC: Place BYOC certificates materials in the install directory location instead of installer directory, |
|
Nodes |
All frontend nodes |
Post-Install BYOC: Update OpenSearch and MongoDB Configurations
If performing post-install BYOC, update OpenSearch and MongoDB configurations with the following steps.
Verification
Follow On-Prem AgileSec Validation Checklist to verify platform functionality.