Configure Fusion 5.9.3 to trust LDAP SSL certificates without cert-manager – Lucidworks

Goal

Enable successful SSL handshake for LDAP security realm connections in Fusion 5.9.3 without using cert-manager or deploying Fusion with tlsEnabled=true.

Environment

Fusion 5.9.x (Self-Hosted)

Installed with:

tlsEnabled=false
No cert-manager on the Kubernetes cluster

Guide

Understand Fusion TLS options and their impact

Fusion supports two mechanisms to trust external HTTPS resources:

Option A: TLS-enabled install with cert-manager
This method configures mutual TLS and pod-specific trust using the tlsEnabled=true Helm value. It allows centralized certificate management and uses the fusion-truststore secret to manage trust across services.
Option B: Manual certificate configuration (without cert-manager)
Suitable when tlsEnabled=false, and cert-manager is unavailable. Requires manually injecting a keystore into the pod filesystem and configuring the JVM options to use it.

This guide focuses on Option B.

Step 1: Create a custom truststore containing your root CA

Use the Java keytool command to create a new JKS file and add your LDAP server’s root CA.

keytool -import -file name_of_cerificate.pem \
  -alias "certificat_name" \
  -keystore truststore.jks \
  -storepass <your-password>

Step 2: Deploy the truststore to the `api-gateway` pod

Encode the .jks file in base64 and place it in a Kubernetes ConfigMap using binaryData, not data, to ensure binary integrity.

apiVersion: v1
kind: ConfigMap
metadata:
  name: ldap-truststore-config
  namespace: fusion
binaryData:
  truststore.jks: <base64-encoded-truststore>

Mount the ConfigMap in your api-gateway pod via its deployment:

volumes:
  - name: ldap-truststore
    configMap:
      name: ldap-truststore-config
      items:
        - key: truststore.jks
          path: truststore.jks

volumeMounts:
  - mountPath: /etc/ssl/custom
    name: ldap-truststore
    readOnly: true

Step 3: Set the JVM truststore path for `api-gateway`

Update the javaToolOptions environment variable in your deployment configuration to point to the mounted truststore:

env:
  - name: javaToolOptions
    value: >
      -Djavax.net.ssl.trustStore=/etc/ssl/custom/truststore.jks
      -Djavax.net.ssl.trustStorePassword=<your-password>

Ensure the path and password match the values used when creating the truststore.

Step 4: Restart the `api-gateway` pod

Apply your changes and redeploy api-gateway. Verify that the pod starts successfully without SSL trust errors.

Step 5: Confirm LDAP login succeeds

Attempt login using an account from your LDAP directory. Check logs for any PKIX path building failed or InvalidAlgorithmParameterException errors. If seen, double-check that:

The truststore is mounted as a binary.
The JVM arguments are correctly configured.
The cert file is complete and valid.

Step 6: Troubleshoot potential LDAP configuration errors

After resolving the SSL handshake, you may encounter errors related to LDAP DN parsing (e.g., LDAP error code 34). These are unrelated to SSL trust and typically indicate misconfigured base DN or group mapping values in the LDAP realm configuration.

Additional notes

Placing the .crt file alone under /etc/ssl/certs is not sufficient for Java SSL. Java requires trust via a JKS or PKCS12 keystore.
Including the LDAP cert in the JWT signing keystore will not affect SSL trust for api-gateway.