[Bug] Helm chart v3.0.0: externalPostgresql.ca sets DB_SSL_CA as file path but server/core/db.js expects base64 content, causing SSL connection failure

[NGPixel]

Discussed in #7939

^{Originally posted by mhorcajada February 25, 2026}
Description
In Helm chart v3.0.0, when configuring an external PostgreSQL with SSL using externalPostgresql.ca, the chart injects the value as a file path into the DB_SSL_CA environment variable. However, the application code in server/core/db.js expects DB_SSL_CA to contain the raw base64 certificate content (without PEM headers), not a file path.
This results in UNABLE_TO_GET_ISSUER_CERT_LOCALLY error and the pod going into CrashLoopBackOff.

Environment:
Wiki.js version: 2.5.312
Helm chart version: 3.0.0
Kubernetes: v1.35.1
PostgreSQL: external, managed by CloudNativePG, SSL enabled

Steps to Reproduce

1. Deploy Wiki.js with Helm chart v3.0.0 using external PostgreSQL with SSL:

nodeExtraCaCerts: "/etc/ssl/certs/vault/vault-ca.pem"

externalPostgresql:
  host: postgres-rw.postgres.svc.cluster.local
  port: 5432
  database: wiki_production
  username: wiki
  existingSecret: wiki-db-secret
  existingSecretKey: postgresql-password
  ssl: true
  ca: /etc/ssl/certs/vault/vault-ca.pem

2. The chart injects DB_SSL_CA as a file path (confirmed via helm get manifest):

- name: DB_SSL_CA
  value: "/etc/ssl/certs/vault/vault-ca.pem"

3. Pod crashes with:

Database Connection Error: UNABLE_TO_GET_ISSUER_CERT_LOCALLY undefined:undefined

Root Cause
In server/core/db.js, DB_SSL_CA is read as base64 content and split into 64-char chunks to reconstruct a PEM:

javascriptif (!_.isEmpty(process.env.DB_SSL_CA)) {
  const chunks = []
  for (let i = 0, charsLength = process.env.DB_SSL_CA.length; i < charsLength; i += 64) {
    chunks.push(process.env.DB_SSL_CA.substring(i, i + 64))
  }
  sslOptions = {
    rejectUnauthorized: true,
    ca: '-----BEGIN CERTIFICATE-----\n' + chunks.join('\n') + '\n-----END CERTIFICATE-----\n'
  }
}

When DB_SSL_CA contains /etc/ssl/certs/vault/vault-ca.pem, the code treats the path string as base64 content and constructs an invalid PEM certificate, causing the SSL verification to fail.

Expected Behavior
Either:

The chart should read the CA file content and inject it as base64 into DB_SSL_CA, OR
The code in db.js should check if DB_SSL_CA is a file path and read its content with fs.readFileSync

Workaround:
Use NODE_TLS_REJECT_UNAUTHORIZED: "0" via extraEnvVars (traffic is still encrypted, only certificate verification is disabled):

extraEnvVars:
  - name: NODE_TLS_REJECT_UNAUTHORIZED
    value: "0"

Update:
Workaround NODE_TLS_REJECT_UNAUTHORIZED: "0" also fails
Tested with both NODE_TLS_REJECT_UNAUTHORIZED: "0" and NODE_EXTRA_CA_CERTS set — the error persists.
The reason is in server/core/db.js: rejectUnauthorized: true is hardcoded in the ssl object passed directly to the pg module, which ignores the NODE_TLS_REJECT_UNAUTHORIZED environment variable entirely.

The only working workaround is ssl: false.

[Suraj-1309]

hey if this bug is still not resolved can I work on this to resolve it.

[NGPixel]

@Suraj-1309 Feel free to submit a PR for it.

[Chelovedus]

@Suraj-1309 Feel free to submit a PR for it.

Hi there. If I want improve wikiJS, I need to create PR in main or scarlett?

[ariesadonis]

Hi, saw this issue about the Helm chart injecting DB_SSL_CA as a file path when the app expects base64. Env var format mismatches like this are nearly impossible to catch without reading both the chart code and the app code together.

I built a CLI that generates a setup doc from a repo's actual env files and configs, surfacing what each variable expects. Happy to run it on Wiki.js and share the output: https://github.com/ariesadonis/onboarding-doc-generator

[ub-victor]

This issue has not yet been addressed. Please assign it to me so I can submit a PR by the end of this week. @NGPixel

[TimoKruth]

Verified on current main (6f042e97, 2026-08-06): confirmed still present by following both sides of the configuration contract.

dev/helm/templates/deployment.yaml assigns .Values.externalPostgresql.ca directly to the DB_SSL_CA environment variable, and the Helm README still describes that value as a certificate file path such as /path/to/ca.

However, server/core/db.js treats every non-empty DB_SSL_CA value as raw base64 certificate content: it wraps the string in PEM headers and 64-character chunks. Unlike the file-based db.sslOptions.ca path, this environment-variable path never calls readFileSync.

Therefore a chart-supplied file path is still converted into invalid PEM content, matching the reported PostgreSQL SSL failure.

[ub-victor]

This issue has not yet been addressed. Please assign it to me so I can submit a PR by the end of this week. @NGPixel

@mhorcajada Can I

[mhorcajada]

This issue has not yet been addressed. Please assign it to me so I can submit a PR by the end of this week. @NGPixel

@mhorcajada Can I

Feel free to submit a PR for it. It will be reviewed by the admins ;-)

[ub-victor]

I have addressed the issue; I eagerly await your review @NGPixel .