On-Prem Certificates Management Guide

How to manage certificates for On-Prem AgileSec Platform production deployments.

All required certificates can be generated and self-signed by the installer, or you can bring your own certificates (BYOC) using your enterprise PKI / organization process.

The following guides are available for managing certificates:

Certificate Overview

The AgileSec platform uses mutual TLS (mTLS) for secure authenticated communication between all services and server components.

At a high level, the AgileSec platform has an external entry point for user/API access and an internal service network where components communicate over encrypted channels. Certificate deployment is aligned to these paths so inbound connections are terminated with the correct endpoint certificate and internal components can authenticate each other consistently.

In addition to runtime traffic, the platform includes a single SSO signing certificate used for SAML-based integrations within the platform. This certificate is used to sign assertions and is configured as part of the integrated SSO setup.

Certificate Types

The AgileSec Platform uses the following certificate types, based on where TLS is terminated and which components require authentication.

Root CA Certificate Chain:

• The Root CA certificate chain establishes the trust anchor for all internal TLS and mTLS communication within the AgileSec Platform. Installer-generated CAs are used for self signing certificates created by generate_certs.sh. 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.

External (User-Facing) Certificates:

• External (user-facing) certificates are used for platform access (Web UI and API ingress). External certificates secure ingress traffic into the platform and are presented to end users and client applications when accessing the Web UI and API endpoints. For production deployments, these certificates should ideally be issued by a publicly trusted (public) CA to ensure browser and client trust. External TLS traffic is terminated at the frontend HAProxy.

Internal Certificates:

• Internal server certificates are used for TLS and mTLS within the platform. Internal certificates secure service-to-service or service-to-platform communication and protect internal endpoints not intended to be publicly exposed. Internal certificates are commonly issued by an internal CA (enterprise PKI like EJBCA) or generated by the installer for proof-of-concepts and first-time installations.

• Client certificates are used for mTLS client authentication when services connect to internal endpoints. By default, the installer can generate a shared client certificate used by all services. Users can also configure the installer to generate separate client certificates per service when stronger isolation is required.

• Admin client certificates (OpenSearch and MongoDB) are privileged client certificates used for administrative connections to OpenSearch and MongoDB (for example, during installation, bootstrap, and management operations). These are distinct from general service-to-service mTLS client certificates.

• SAML (SSO) and IdP signing certificate and key is used by the platform when it acts as the Identity Provider (IdP) for SSO integrations (for example, OpenSearch Dashboards). The platform uses this credential to sign SAML assertions, and the corresponding public certificate is trusted by the integrated Service Provider to validate those assertions.

• Security Manager (SM) keystore (PKCS#12) is a service-specific keystore used by the Security Manager (SM) to generate and store the customer master key (CMK). The keystore is also used by SM for secure key material storage and retrieval.