3.6 3.5 3.4
3.6 3.5 3.4

BYOC Approach 2: BYOC All Certificate Material

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

  1. Generate a baseline certificate structure from the installer on backend-1.

  2. Deploy the generated structure and .env files to all other nodes.

  3. Replace the installer-generated CA with BYOC CA chain in place.

  4. Generate BYOC materials.

    1. Review requirements for each certificate type.

    2. Ensure BYOC material names match installer-generated materials.

    3. If applicable, create combo .PEMs (Certificate → Intermediates (if applicable) → Key).

  5. Replace the installer generated certificates and keys with BYOC materials in place.

    1. Use the same filenames and directories as installer-generated material on all nodes.

  6. 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

  1. Set variable $installer_dir on backend-1 to easily copy and paste guide instructions into terminal:

    export installer_dir=</path-to-installer-directory>
    
  1. 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.

  1. Generate baseline certificate directory structure.

  2. Deploy baseline certificate structure and .env files 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

-n

No

Non-interactive mode: no prompts, overwrite files.

-e <path>

No

Path to .env file. Defaults to ../.env

-v

No

Verbose mode: outputs additional console statements for debugging.

-V <directory>

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


agilesec-rootca-cert.pem

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 agilesec-rootca-cert.pem alone. The installer’s chain validation does not use chain material from a combo file or from a leaf cert with an intermediate appended. Omitting intermediates from agilesec-rootca-cert.pem will cause chain validation to fail, even if those same intermediates are correctly included elsewhere (e.g. the BYOC external certificate's combo file).

3

Protective Permissions

Apply chmod 400 to all BYOC materials.

Replace CA Trust Chains

Placement

Details

1

BYOC Filename

agilesec-rootca-cert.pem

2

BYOC Materials Location

$installer_dir/certificates/ca/agilesec-rootca-cert.pem

Note for Post-Install BYOC:

Place BYOC certificates materials in the install directory location instead of installer directory, $agilesec_installation_dir/certificates/ca/agilesec-rootca-cert.pem. See Post-Install BYOC instructions below for details.

3

Nodes

All Nodes

Pre-Install BYOC Steps

The following steps must be performed for CA chain replacement pre-installation:

  1. Place the CA chain on each node. Copy agilesec-rootca-cert.pem to $installer_dir/certificates/ca/agilesec-rootca-cert.pem on every node. This is the filename and path the installer expects, so no configuration changes are required.

  2. Protect the CA chain with chmod 400:

    chmod 400 agilesec-rootca-cert.pem
    
  3. Remove unneeded files generated by generate_certs.sh. The installer-generated CA private key (agilesec-rootca-key.pem) and serial file (agilesec-rootca-cert.srl) are not required once the Root CA is replaced. Delete both files from $installer_dir/certificates/ca after completing CA replacement.

  4. Install the CA into the system trust store with tune.sh. On each node, run tune.sh to install the updated root CA into the node trust store:

    cd $installer_dir
    sudo ./scripts/tune.sh -u <user>
    
Post-Install BYOC Steps

Important: Shut down the cluster before performing these steps.

Perform these steps on all backend nodes, primary frontend (frontend-1), scan nodes, and the coordinator node:

  1. Place the updated CA chain in AgileSec’s installed location $agilesec_installation_dir/certificates/ca/agilesec-rootca-cert.pem.

  2. Copy the updated CA chain to the installer directory (tune.sh reads from this location) at $installer_dir/certificates/ca/agilesec-rootca-cert.pem.

  3. Protect both copies with chmod 400.

  4. The installer-generated CA private key (agilesec-rootca-key.pem) and serial file (agilesec-rootca-cert.srl) are not required once the Root CA is replaced. Remove these unneeded files, if present.

  5. Install the CA into the system trust store with tune.sh. On each node, run tune.sh to install the updated root CA into the node trust store:

   cd $installer_dir
   sudo ./scripts/tune.sh -u <user>
  1. Update the Root CA trust bundle copy maintained by OpenSearch under its service directory $agilesec_installation_dir/services/opensearch/config/certs/agilesec-rootca-cert.pem.

  2. Update the JVM default truststore. tune.sh only updates the OS-level trust store, not the JVM's default cacerts truststore. Java service relying on the default JVM truststore for TLS trust will not pick up the new Root CA unless this update is done manually:

    cd $agilesec_installation_dir
    ./bin/java/bin/keytool -delete -alias "root.<analytics_internal_domain>" \
      -keystore bin/java/lib/security/cacerts \
      -storepass changeit
      
    ./bin/java/bin/keytool -noprompt -importcert -trustcacerts \
      -alias "root.<analytics_internal_domain>" \
      -file certificates/ca/agilesec-rootca-cert.pem \
      -keystore bin/java/lib/security/cacerts \
      -storepass changeit
    
  1. After completing all post-install BYOC certificate replacements, restart the cluster.


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

agilesec-analytics-server-cert.pem

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 agilesec-rootca-cert.pem. agilesec-rootca-cert.pem is the trust anchor file for internal platform certificates and is not consulted for the external certificate's chain validation, even if the external certificate is signed by a different CA than your internal certificates.

2

Private Key Filename

agilesec-analytics-key.pem

3

Certificate Key Combo File

agilesec-analytics-server-combo-cert-key.pem

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

<analytics_hostname>.<analytics_domain> must be included as a DNS SAN for clients to validate against.

5

CN

May be set to the same FQDN for readability but is not relied on for validation.

6

Protective Permissions

Apply chmod 400 to all BYOC materials.

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

  • agilesec-analytics-server-cert.pem

  • agilesec-analytics-key.pem

  • agilesec-analytics-server-combo-cert-key.pem

BYOC Directory Location

$installer_dir/certificates/<analytics_hostname>.<analytics_domain>

Note for Post-Install BYOC:

Place BYOC certificates materials in the install directory location instead of installer directory, $agilesec_installation_dir/certificates/<analytics_hostname>.<analytics_domain>.

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:

  1. 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.

  2. 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

agilesec-internal-server-cert.pem

If signed by an intermediate CA, concatenate: Certificate → Intermediates.

2

Private Key Filename

agilesec-internal-server-key.pem

3

Certificate Key Combo File

agilesec-internal-server-combo-cert-key.pem

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 server_certificate_subject from .env, converted from comma-delimited/most-specific-first to slash-delimited/least-specific-first for the CSR.

Example: server_certificate_subject="OU=Server,O=Keyfactor,ST=California,C=US" → CSR subject: /C=US/ST=California/O=Keyfactor/OU=Server/CN=*.kf-agilesec.internal

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: *.<analytics_internal_domain>

For single certificate with SANS:

  • Single-node: <analytics_hostname>.<analytics_internal_domain>

  • Multi-node: include each node’s internal hostname, for example:
    backend-1.<analytics_internal_domain>, backend-2.<analytics_internal_domain>, frontend-1.<analytics_internal_domain>, scan-1.<analytics_internal_domain>, coordinator.<analytics_internal_domain>, etc.

Info: Scan nodes are numbered and variable in count; coordinator is always singular

7

Key Usage

Digital Signature. Do not mark critical.

8

Extended Key Usage

Server Authentication (OID 1.3.6.1.5.5.7.3.1)
Client Authentication (OID, 1.3.6.1.5.5.7.3.2)

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 (-----BEGIN PRIVATE KEY-----), not SEC1 format (-----BEGIN EC PRIVATE KEY-----). Java-based key readers cannot parse SEC1 formatted EC keys and will fail with InvalidKeySpecException: Neither RSA, DSA nor EC worked. Convert with:

openssl pkey -in <sec1-key.pem> -out <pkcs8-key.pem>

Confirm the resulting key PEM file begins with -----BEGIN PRIVATE KEY----- before proceeding.

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 chmod 400 to all BYOC materials.

Place BYOC Internal Server Certificates

Deploy BYOC Internal Server Certificate materials to the following locations and nodes:

Placement

Details

BYOC Files

  • agilesec-internal-server-cert.pem

  • agilesec-internal-server-key.pem

  • agilesec-internal-server-combo-cert-key.pem

BYOC Materials Location

$installer_dir/certificates/<analytics_internal_domain>/

Note for Post-Install BYOC:

Place BYOC certificates materials in the install directory location instead of installer directory, $agilesec_installation_dir/certificates/<analytics_internal_domain>/

Nodes

All backend nodes
All frontend nodes
All scan 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 client_certificate_subject from .env, converted from comma-delimited/most-specific-first to slash-delimited/least-specific-first order for the CSR.

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: client_certificate_subject="OU=Client,O=Keyfactor,ST=California,C=US" and client_certificate_name_prefix="shared-client"

converts to →

/C=US/ST=California/O=Keyfactor/OU=Client/CN=shared-client.kf-agilesec.int

CN

Set to <client_certificate_name_prefix>.<agilesec_internal_domain>, using the prefix from .env.

CN distinguishes individual client certs since the base subject fields are shared across all clients.

Key Usage

Digital Signature. Do not mark critical.

Extended Key Usage

Client Authentication (OID, 1.3.6.1.5.5.7.3.2).

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 (-----BEGIN PRIVATE KEY-----), not SEC1 format (-----BEGIN EC PRIVATE KEY-----). Java-based key readers cannot parse SEC1 formatted EC keys and will fail with InvalidKeySpecException: Neither RSA, DSA nor EC worked. Convert with:

openssl pkey -in <sec1-key.pem> -out <pkcs8-key.pem>

Confirm the resulting key PEM file begins with -----BEGIN PRIVATE KEY----- before proceeding.

Signature hash

SHA-256 (Minimum), SHA-384, SHA-512

Trust Chain

Must chain back to the Root CA being used.

Protective Permissions

Apply chmod 400 to all BYOC materials.

Ensure BYOC materials meet the following additional requirements for each model:

Model 1: Single Shared Client Certificate Files Requirements

When use_single_client_cert=true, generate_certs.sh generates a single shared client certificate used by all platform services for mTLS client authentication.

Single Shared Client Certificate File Requirement

Details

1

Shared Client Certificate Filename

shared-client-cert.pem

If signed by an intermediate CA, concatenate: Certificate → Intermediates.

2

Shared Client Key Filename

shared-client-key.pem

3

Shared Client Certificate-Key Combo File

shared-client-combo-cert-key.pem

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

Shared Client Keystore Filename

PKCS#12 keystore containing the certificate, intermediate certs and key.

shared-client.p12

Note: P12 files must contain the client certificate, client key, and intermediate certificates (if applicable).

5

Share Client Keystore Password Filename

Password for shared client keystore

agilesec-client-keystore.pass


6

Protective Permissions

Apply chmod 400 to all BYOC materials.

Note for Post-Install BYOC: If replacing the shared client certificate/keystore after AgileSec installation, the keystore password must also be updated in the following locations:

  • bin/scheduler_entrypoint.sh — -Djavax.net.ssl.keyStorePassword=<password>

  • bin/analytics_manager_entrypoint.sh — -Djavax.net.ssl.keyStorePassword=<password>

(For pre-install BYOC, these updates are not required; these values are generated correctly by generate_env.sh/generate_certs.sh during initial setup.)

Model 2: Per-Service Client Certificate Files Requirements

When use_single_client_cert=false, generate_certs.sh generates a separate client certificate per service. This provides stronger isolation and enables independent rotation of a single service credential without impacting others.

Client

Nodes

File Type

Required File Name

1

API / CBOM

Frontend

Client certificate

api-client-cert.pem

If signed by an intermediate CA, concatenate: Certificate → Intermediates.

2



Client key

api-client-key.pem

3



Client certificate-key combo

api-client-combo-cert-key.pem

Concatenate in the following order: Certificate file (already including intermediates if applicable) → Key.

Make sure each intermediate certificate is concatenated only once.

4

FluentD

Note: Fluentd files are only required when v2_sensors are enabled


Backend

Client Certificate

fluentd-client-cert.pem

If signed by an intermediate CA, concatenate: Certificate → Intermediates.

5



Client key

fluentd-client-key.pem

6

HA Proxy

Frontend,
Backend,
Scan

Client certificate-key combo

haproxy-client-combo-cert-key.pem

Concatenate in the following order: Certificate file (already including intermediates if applicable) → Key.

7

Indexing Service

Backend

Client certificate

indexing-service-client-cert.pem

If signed by an intermediate CA, concatenate: Certificate → Intermediates.

8



Client key

indexing-service-client-key.pem

9



Client certificate-key combo

indexing-service-client-combo-cert-key.pem

Concatenate in the following order: Certificate file (already including intermediates if applicable) → Key.

10

Ingestion Service

Backend

Client certificate

ingestion-service-client-cert.pem

If signed by an intermediate CA, concatenate: Certificate → Intermediates.

11



Client key

ingestion-service-client-key.pem

12



Client certificate-key combo

ingestion-service-client-combo-cert-key.pem

Concatenate in the following order: Certificate file (already including intermediates if applicable) → Key.

13

Manager Service

Backend

Client certificate

analytics-manager-client-cert.pem

If signed by an intermediate CA, concatenate: Certificate → Intermediates.

14



Client key

analytics-manager-client-key.pem

15



Client certificate-key combo

analytics-manager-client-combo-cert-key.pem

Concatenate in the following order: Certificate file (already including intermediates if applicable) → Key.

16



Client keystore

analytics-manager-client.p12

Note: P12 files must contain the client certificate, client key, and intermediate certificates (if applicable).

Pre-install BYOC: set password in file $installer_dir/certificates/<analytics_internal_domain>/agilesec-client-keystore.pass.
Post-install BYOC: set the password in $agilesec_installation_dir/bin/analytics_manager_entrypoint.sh

17

OpenSearch Dashboards

Frontend

Client certificate

opensearch-dashboards-client-cert.pem

If signed by an intermediate CA, concatenate: Certificate → Intermediates.

18



Client key

opensearch-dashboards-client-key.pem

19

Platform Sensors

Backend,
Scan

Client certificate

platform-sensor-client-cert.pem

If signed by an intermediate CA, concatenate: Certificate → Intermediates.

20



Client key

platform-sensor-client-key.pem

21

Scheduler

Backend,
Scan

Client certificate

scheduler-client-cert.pem

If signed by an intermediate CA, concatenate: Certificate → Intermediates.

22



Client key

scheduler-client-key.pem

23



Client certificate-key combo

scheduler-client-combo-cert-key.pem

Concatenate in the following order: Certificate file (already including intermediates if applicable) → Key.

24


Backend,
Scan,
Frontend-1

Client keystore

scheduler-client.p12

Note: scheduler.client.p12 is needed on frontend-1 only when performing pre-install BYOC replacement.

Note: P12 files must contain the client certificate, client key, and intermediate certificates (if applicable).

Pre-install BYOC: set password in file $installer_dir/certificates/<analytics_internal_domain>/agilesec-client-keystore.pass.
Post-install BYOC: set the password in $agilesec_installation_dir/bin/scheduler_entrypoint.sh.

Important: Apply protective permissions with chmod 400 to all BYOC materials.

Warning: For combo certificates, make sure each intermediate certificate is concatenated only once.

Place BYOC mTLS Certificates

Deploy BYOC materials to the following locations and nodes.

Placement

Details

BYOC Materials Location

$installer_dir/certificates/<analytics_internal_domain>/

Note for Post-Install BYOC:

Place BYOC certificates materials in the install directory location instead of installer directory, $agilesec_installation_dir/certificates/<analytics_internal_domain>.

Nodes

Model 1: Shared Client Certificate

  • All backend nodes

  • All frontend nodes

  • All scan nodes

Model 2: Per-Service Client Certificate Files

  • See Per-Service Client Certificate Files Requirements for specific nodes placement.


Model 2: Update OpenSearch Configuration

If utilizing model 2, per-service client certificate files, perform the following steps to update OpenSearch configuration.

Model 2: Update OpenSearch Configuration Steps
  1. Add the indexing services' client certificate DN to roles_mapping.ymlon backend-1:

    1. Pre-install BYOC: Update $installer_dir/templates/opensearch/roles_mapping.yml

    2. Post-Install BYOC: Update the post-install OpenSearch roles mapping, not the installer directory, $agilesec_installation_dir/services/opensearch/config/opensearch-security/roles_mapping.yml

    3. Add the following to roles_mapping.yml:

      agilesec_ingest_role:
        reserved: false
        backend_roles:
          - "agilesec_ingest_role"
        # List of client cert CNs
        users:
        - "CN=indexing-service-client.<analytics_internal_domain>,<client_certificate_subject>"
      {{OPENSEARCH_INGESTION_USERS}}
        description: "Data ingestion"
      
  2. Create a monitor only role in roles.yml on backend-1:

    1. Pre-Install BYOC: Update $installer_dir/templates/opensearch/roles.yml

    2. Post-Install BYOC: Update the post-install OpenSearch roles, not the installer directory, $agilesec_installation_dir/services/opensearch/config/opensearch-security/roles.yml

    3. Add the following to roles.yml:

        monitor_only:
          reserved: false
          cluster_permissions:
            - "cluster:monitor/nodes/info"
            - "cluster:monitor/main"
          index_permissions: []
      
  3. Map HAProxy’s health-check identity to the monitor-only role at the end of roles_mapping.yml on backend-1:

    1. Pre-install BYOC: Update $installer_dir/templates/opensearch/roles_mapping.yml

    2. Post-Install BYOC: Update the post-install OpenSearch roles mapping, not the installer directory, $agilesec_installation_dir/services/opensearch/config/opensearch-security/roles_mapping.yml

    3. Add the following to roles_mapping.yml:

      monitor_only:
        reserved: false
        backend_roles: []
        hosts: []
        users:
          - "CN=haproxy-client.<analytics_internal_domain>,<client_certificate_subject>"
      
    4. Replace <client_certificate_subject> with the value set in multi_node_config.conf or single_node_config.conf.

  4. If OpenSearch configuration steps above were updated post-install, run the following on backend-1:

    export AGILESEC_INSTALLATION_DIR=$agilesec installation dir
    export JAVA_HOME=$AGILESEC_INSTALLATION_DIR/bin/java
    export OPENSEARCH_HOME=$AGILESEC_INSTALLATION_DIR/services/opensearch
    
    $OPENSEARCH_HOME/plugins/opensearch-security/tools/securityadmin.sh -f $OPENSEARCH_HOME/config/opensearch-security/roles.yml \
       -t roles \
       -icl \
       -key $AGILESEC_INSTALLATION_DIR/certificates/<analytics_internal_domain>/opensearch-admin-user-key.pem \
       -cert $AGILESEC_INSTALLATION_DIR/certificates/<analytics_internal_domain>/opensearch-admin-user-cert.pem \
       -cacert $AGILESEC_INSTALLATION_DIR/certificates/ca/agilesec-rootca-cert.pem \
       -h backend-1.<analytics_internal_domain> -p 9200 -nhnv
    
    $OPENSEARCH_HOME/plugins/opensearch-security/tools/securityadmin.sh -f $OPENSEARCH_HOME/config/opensearch-security/roles_mapping.yml \
       -t rolesmapping \
       -icl \
       -key $AGILESEC_INSTALLATION_DIR/certificates/<analytics_internal_domain>/opensearch-admin-user-key.pem \
       -cert $AGILESEC_INSTALLATION_DIR/certificates/<analytics_internal_domain>/opensearch-admin-user-cert.pem \
       -cacert $AGILESEC_INSTALLATION_DIR/certificates/ca/agilesec-rootca-cert.pem \
       -h backend-1.<analytics_internal_domain> -p 9200 -nhnv
    
    1. Replace <analytics_internal_domain> with value from multi_node_config.conf or single_node_config.conf.

  5. If performing pre-install BYOC, complete AgileSec installation before proceeding with the next steps.

  6. Replace HAProxy frontend section fe_opensearch with the following on all backend and scan nodes:

    frontend fe_opensearch
        bind <backend | scan host>.<analytics_internal_domain>:50443
        mode tcp
        option tcplog
        default_backend be_opensearch
    
  7. Replace HAProxy backend section be_opensearch with the following on all backend and scan nodes:

    backend be_opensearch
        mode tcp
        timeout connect 10s
        timeout server  10m
        timeout client  10m
        default-server inter 5s fastinter 2s downinter 10s fall 3 rise 2 on-marked-down shutdown-sessions
        server os1 backend-1.<analytics_internal_domain>:9200 track be_opensearch_healthcheck/ois1
        server os2 backend-2.<analytics_internal_domain>:9200 track be_opensearch_healthcheck/ois2 backup
    
    # Health-check-only backend - HAProxy authenticates as haproxy-client, never carries real traffic
    backend be_opensearch_healthcheck
        mode http
        balance roundrobin
        option httpchk
        http-check send meth GET uri /_nodes/_local
        http-check expect status 200
        default-server inter 5s fastinter 2s downinter 10s fall 3 rise 2 ca-file $agilesec_installation_dir/certificates/ca/agilesec-rootca-cert.pem crt $agilesec_installation_dir/certificates/<analytics_internal_domain>/haproxy-client-combo-cert-key.pem
        server ois1 backend-1.<analytics_internal_domain>:9200 ssl verify none sni str(backend-1.<analytics_internal_domain>) check
        server ois2 backend-2.<analytics_internal_domain>:9200 ssl verify none sni str(backend-2.<analytics_internal_domain>) check
    
    1. If you have more than two backend nodes, add additional server entries to be_opensearch and be_opensearch_healthcheck (see lines 18-19). Under be_opensearch, additional server entries for all non-local nodes must have backup at the end.

    2. Warning: If you have updated names for backend-1 and backend-2, make sure they are updated accordingly.

  8. Restart HAProxy on all backend and scan nodes. (See On-Prem Managing Services.)


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.

  • AgileSec’s installer builds the DN from client_certificate_subject (.env) and CN=admin-user.<analytics_internal_domain>.

  • The .env value is comma-delimited, most-specific-first (e.g. OU=Client,O=Keyfactor,ST=California,C=US).

  • The CSR needs slash-delimited, least-specific-first: reverse the field order, then join with slashes.

For OpenSearch: Must exactly match plugins.security.authcz.admin_dn in opensearch.yml. Update this value when rotating the admin cert.

For MongoDB: Mapped to an $external user with root-level access. Replacing the cert without updating the corresponding $external user's DN will lock out root-level Mongo access until corrected.

Both OpenSearch and MongoDB:

  • OpenSearch and MongoDB both expect RFC 2253/LDAP order: most-specific first, the reverse of openssl x509 -subject's default output (C=...,ST=...,O=...,OU=...,CN=...).

  • Use openssl x509 -in <cert> -noout -subject -nameopt RFC2253 to get the correctly-ordered string for both config files. Do not hand-reverse the default output to avoid transposing any fields.

2

CN

Single shared certificate:

  • admin-user.<analytics_internal_domain>

Per-service client certificates:

  • mongodb-admin-user.<analytics_internal_domain>

  • opensearch-admin-user.<analytics_internal_domain>

3

Key Usage

Digital Signature. Do not mark critical.

4

Extended Key Usage

Client Authentication (OID, 1.3.6.1.5.5.7.3.2).

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 (-----BEGIN PRIVATE KEY-----), not SEC1 format (-----BEGIN EC PRIVATE KEY-----). Java-based key readers cannot parse SEC1 formatted EC keys and will fail with InvalidKeySpecException: Neither RSA, DSA nor EC worked. Convert with:

openssl pkey -in <sec1-key.pem> -out <pkcs8-key.pem>

Confirm the resulting key PEM file begins with -----BEGIN PRIVATE KEY----- before proceeding.

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:

Model 1: Single Shared Client Certificate Files Requirements

When use_single_client_cert=true, generate_certs.sh generates a single shared client certificate used by all platform services for administrative authentication to both MongoDB and OpenSearch.

Single Shared Client Certificate File Requirement

Details

Admin User Certificate Filename

admin-user-cert.pem

If signed by an intermediate CA, concatenate: Certificate → Intermediates.

Admin User Key Filename

admin-user-key.pem

Admin User Certificate-Key Combo File

Certificate-key combined file.

admin-user-combo-cert-key.pem

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."

Protective Permissions

Apply chmod 400 to all BYOC materials.

Model 2: Per-Service Client Certificate Files Requirements

When use_single_client_cert=false, generate_certs.sh generates a separate client certificate per service. This model provides stronger isolation and enables independent rotation of a single service credential without impacting others.

Per-Service Client Certificates File Requirement

Details

MongoDB Admin User Certificate-Key Combo File

Certificate-key combined file.

mongodb-admin-user-combo-cert-key.pem

Concatenate in the following order: Certificate → Intermediates (if applicable) → Key

Warning: Missing intermediates commonly cause client errors such as "unable to verify the first certificate."

OpenSearch Admin User Certificate Filename

opensearch-admin-user-cert.pem

If signed by an intermediate CA, concatenate: Certificate → Intermediates.

OpenSearch Admin User Key Filename

opensearch-admin-user-key.pem

Protective Permissions

Apply chmod 400 to all BYOC materials.

Place BYOC Admin Certificates

Deploy BYOC materials to the following locations and nodes.

Placement

Details



BYOC Materials Location

$installer_dir/certificates/<analytics_internal_domain>/

Note for Post-Install BYOC:

Place BYOC certificates materials in the install directory location instead of installer directory, $agilesec_installation_dir/certificates/<analytics_internal_domain>/.

Nodes

All backend nodes
All frontend 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

idp-cert.pem

2

IdP Encrypted Private Key Filename

idp-enc-key.pem

3

Private Key Password Filename

saml.pass

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

Digital Signature, Non Repudiation, mark as critical

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 chmod 400 to all BYOC materials.

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

$installer_dir/certificates/<analytics_internal_domain>

Note for Post-Install BYOC:

Place BYOC certificates materials in the install directory location instead of installer directory, $agilesec_installation_dir/certificates/<analytics_internal_domain>.

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.

Post-Install BYOC Steps

If performing post-install BYOC, perform the following steps:

  1. Extract the certificate as a single-line base64 blob value (no PEM headers):

    openssl x509 -in idp-cert.pem -outform DER | openssl base64 -A
    
  1. On all backend and frontend nodes running OpenSearch, update the file $agilesec_installation_dir/services/opensearch/config/opensearch-security/idp-metadata.xml and replace the certificate value in <ds:X509Certificate> with the base64 value extracted in step 1. Leave all other values unchanged.

    <EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="ui_idp">
        <IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
            <KeyDescriptor use="signing">
                <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
                <ds:X509Data>
                    <ds:X509Certificate><---value from step 1---></ds:X509Certificate>
                </ds:X509Data>
                </ds:KeyInfo>
            </KeyDescriptor>
            <SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://agilesec.us-west-1.kf-agilesec.com/sso"/>
            <SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://agilesec.us-west-1.kf-agilesec.com/signout"/>
        </IDPSSODescriptor>
    </EntityDescriptor>
    
  1. On the frontend node running API, replace the file $agilesec_installation_dir/services/api/dist/modules/v1/saml/config/privatekey.pemwith idp-enc-key.pem

  2. On the frontend node running API, set the password for the encrypted private key idp-enc-key.pem in $agilesec_installation_dir/config_envs/api in the SAML_PASSPHRASE parameter.

  3. Run the following commands on backend-1 to update idp-metadata config stored in MongoDB:

    METADATA_ESCAPED=$(sed -e 's/\\/\\\\/g' -e 's/"/\\"/g' $agilesec_installation_dir/services/opensearch/config/opensearch-security/idp-metadata.xml | awk '{printf "%s\\n", $0}')
    $agilesec_installation_dir/bin/mongosh "mongodb://backend-1.<agilesec_internal_domain>:27017/platform" \
      --tls \
      --tlsCAFile $agilesec_installation_dir/certificates/ca/agilesec-rootca-cert.pem \
      --tlsCertificateKeyFile $agilesec_installation_dir/certificates/<agilesec_internal_domain/[admin-user-combo-cert-key.pem | mongodb-admin-user-combo-cert-key.pem] \
      --authenticationMechanism MONGODB-X509 \
      --authenticationDatabase '$external' \
      --eval 'db.settings.updateOne({ name: "idp-metadata" }, { $set: { value: "'"${METADATA_ESCAPED}"'" } })'
    
    
  1. View idp-metadata in MongoDB and confirm updates were effective:

    $agilesec_installation_dir/bin/mongosh "mongodb://backend-1.<agilesec_internal_domain>:27017/platform" \
      --tls \
      --tlsCAFile $agilesec_installation_dir/certificates/ca/agilesec-rootca-cert.pem \
      --tlsCertificateKeyFile $agilesec_installation_dir/certificates/<agilesec_internal_domain/[admin-user-combo-cert-key.pem | mongodb-admin-user-combo-cert-key.pem] \
      --authenticationMechanism MONGODB-X509 \
      --authenticationDatabase '$external' \
      --eval 'printjson(db.settings.findOne({ name: "idp-metadata" }))'
    
  1. Restart OpenSearch on frontend and backend nodes. (See On-Prem Managing Services.)

  2. Restart API service on frontend nodes. (See On-Prem Managing Services.)


Verification

Follow On-Prem AgileSec Validation Checklist to verify platform functionality.