<< Click to Display Table of Contents >> Raynet One > 2026.1 > Installation and Operations Guide > Raynet One On-Premises Installation and Operations Guide  Certificate Management

These corporate PKI certificates are not generated by the system.  They must be supplied by the organization's PKI/Security team and integrated into the Docker Compose configuration. If no certificates are configured, the system runs without TLS.

 

 

The system uses nginx-proxy for SSL/TLS termination.

 

You can use either:

1.Self-signed certificates (testing / non-production), or

2.Corporate PKI / Private CA certificates (recommended for production)

 

Option A: Self-signed Certificates (Testing)

Intended for non-production testing environments.

 

Option B: Corporate PKI / Private CA (Production)

To use custom certificates, you must configure certificate mounts and related settings in compose.yml.

 

Important:

If your deployment supports Docker Compose override files (for example compose.certs.yml) it is recommended to apply the certificate configuration there instead of modifying compose.yml modifying directly.

Prefer using an override compose file (e.g., compose.certs.yml) if available.

 

 

1. Prepare Certificates

Note: Certificate creation and signing are outside the scope of this documentation. The following steps describe how to integrate existing certificates into the Raynet One Docker Compose setup.

 

Place certificate files in the certs/ directory:

 

•certs/shared.crt – Public certificate (wildcard recommended, e.g., *.raynetone.example.com)

•certs/shared.key – Private key

•certs/rootCA.crt – Root CA certificate for system trust

•certs/rootCA.pem – Root CA in PEM format (for Java services such as Keycloak)

 

TLS certificates (shared.crt and shared.key) define the server identity used for HTTPS.

Root CA certificates (rootCA.crt and rootCA.pem) establish trust for HTTPS connections to services using certificates issued by the same CA.

 

2. Configure compose.yml

If your current approach requires editing compose.yml, follow these steps:

Enable certificate usage for the relevant services by removing comment markers (#) from the following lines:

• Lines beginning with # CERT_NAME: shared

•All CA certificates must be provided in PEM format with a .crt or.pem extension as required by the target OS (rootCA).

 

3. Ensure Internal Trust (Root CA)

When services communicate over HTTPS using a private  or corporate CA, all involved containers must trust the Root CA.

Enable the appropriate volume mounts for the Root CA certificate in compose.yml for example:

 

# volumes:

# -./certs/rootCA.pem:opt/truststore2/cootCA.pem

or:

# volumes:

# -./certs/rootCA.crt:/tmp/certs/rootCA.crt

 

After mounting the Root CA into the container, ensure the service startup process installs the CA certificate into the container's system trust store.

 

Keycloak must trust the certificate presented by the frontend during authentication flows. This applies to self-signed certificates (testing) as well as private or corporate CA certificates (production).

 

 

Note:

Keycloak validates the frontend TLS certificate against its configured truststore. A complete certificate chain (including all intermediate certificates) is required for successful validation. If intermediate certificates are missing, the TLS handshake will fail, which prevents Keycloak from generating tokens.