Self-Signed Certificates¶

Huddo and Huddo Boards check the TLS certificate of every server they call, such as HCL Connections, MongoDB, S3 or your SMTP gateway. If one of these uses a self-signed certificate, or one from a private certificate authority (CA), those calls fail. The pod logs show errors like SELF_SIGNED_CERT_IN_CHAIN or UNABLE_TO_VERIFY_LEAF_SIGNATURE.

There are two ways to fix this:

Add the CA certificate (recommended)
Turn off certificate checks (not recommended)

Add the CA certificate¶

The charts mount a CA bundle into every app service and set NODE_EXTRA_CA_CERTS to it, so the services trust certificates it signs. Provide the bundle in one of two ways. All the options are in the reference for Huddo and Huddo Boards.

Info

Requires huddo-cp, huddo, huddo-boards >= 2.1.0 or huddo-boards-cp >= 2.3.0. For older Boards charts, see Manual mounting.

Option 1 — let the chart create the secret¶

Paste your CA bundle (PEM) into your config file. The chart creates the secret and mounts it:

global:
  internalCa:
    pem: |
      -----BEGIN CERTIFICATE-----
      ...your CA certificate...
      -----END CERTIFICATE-----

Option 2 — create the secret yourself¶

Useful if you manage certificates separately, or share the CA with other workloads. Create the secret in the namespace you install into, e.g. connections on Component Pack. The file name becomes the key, and cert.pem matches the chart default:

kubectl create secret generic internal-ca --from-file=cert.pem -n <namespace>

Then reference it in your config file:

global:
  internalCa:
    existingSecret: internal-ca

Tip

If your secret uses a different key, or you want a different mount path or secret name, set global.internalCa.key, .mountPath or .secretName.

Either way, upgrade the release. The bundle is mounted into every app service, with no per-service configuration.

The secret that Option 1 creates is kept when you helm uninstall the release.

Huddo installed alongside Huddo Boards

Both charts create their secret as internal-ca in the same namespace, so only one release can create it. If both use pem, the second install fails because the secret belongs to the other release.

Give the CA to the Boards release (either option), then point the Huddo release at the same secret:

global:
  internalCa:
    existingSecret: internal-ca

Services that do not use the bundle¶

SocketCluster, SeaweedFS, OpenSearch and draw.io do not mount the bundle. They do not usually call servers with private certificates. For an external OpenSearch cluster with a private certificate, see OPENSEARCH_TLS_REJECT_UNAUTHORIZED under Search.

Turn off certificate checks¶

Warning

Not recommended for production. Services then accept any certificate, including an attacker's.

Set NODE_TLS_REJECT_UNAUTHORIZED: '0'.

For Huddo, set it once in global.env, which applies to every app service:

global:
  env:
    NODE_TLS_REJECT_UNAUTHORIZED: '0'

For Huddo Boards, set it on core, user and provider, and on events if your email server needs it:

core:
  env:
    NODE_TLS_REJECT_UNAUTHORIZED: '0'
user:
  env:
    NODE_TLS_REJECT_UNAUTHORIZED: '0'
provider:
  env:
    NODE_TLS_REJECT_UNAUTHORIZED: '0'

# if required for your email server
events:
  env:
    NODE_TLS_REJECT_UNAUTHORIZED: '0'