feat(lightning): support loading LND TLS certificate from file

[Danswar]

Problem

The LND TLS certificate is currently loaded only from the LIGHTNING_API_CERTIFICATE env var, which is hand-copied. When the live cert on the node is rotated/regenerated, the env var goes stale and the app starts throwing recurring "self-signed certificate" errors on dfxdev.

Change

Adds support for an optional env var LIGHTNING_API_CERTIFICATE_PATH. When it is set and the file is readable, the app reads the live certificate directly from disk. Otherwise it falls back to the existing LIGHTNING_API_CERTIFICATE env var, completely unchanged.

• New module-level readCert() helper in src/config/config.ts feeds the existing certificate config field.
• The lightning-client TLS logic (HTTPS agent ca) is untouched.
• .env.example documents the new optional var.

Backward compatibility

Fully backward compatible. With no LIGHTNING_API_CERTIFICATE_PATH set, behavior is identical to before (and an unreadable path silently falls back to the env var). Safe to deploy first — no behavior change until the path env is set.

Related

• Paired with server-repo PR Feature/dev 533 bank account api #366 (docker-compose mounts the cert file).
• Part of the same fix as LDS LightningDotSpace/api PR Masternode Resign / KYC #200.

Testing

• npx tsc --noEmit — passes
• jest config + lightning specs — 18 passing

[davidleomay]

Suggestion: remove the fallback entirely

The silent catch-all fallback to LIGHTNING_API_CERTIFICATE makes deployment errors invisible. If LIGHTNING_API_CERTIFICATE_PATH is set but the file is missing or unreadable (misconfigured volume mount, wrong path, deploy order mistake), we silently fall back to the Vault-stored copy — and won't notice until the live cert rotates and goes stale, which is the exact problem this PR aims to fix.

Hidden fallbacks are also confusing when debugging: "is my app using the live cert or the stale one?"

Since:

1. fix(lightning): reuse https Agent across LND requests #3854 (cached https.Agent) already prevents the TLS error from stale certs
2. The paired infra PR Feature/dev 533 bank account api #366 ensures the file is mounted at container start
3. No scenario exists where the file path is set but shouldn't be used

→ I'd remove the fallback and the LIGHTNING_API_CERTIFICATE env var entirely. If the path is set, read it or crash — that makes misconfigurations visible immediately.

[Danswar]

Done — removed the fallback. readCert() now reads LIGHTNING_API_CERTIFICATE_PATH and throws if it's unset/unreadable, so a broken mount fails loudly instead of silently using a stale cert. Dropped LIGHTNING_API_CERTIFICATE from .env.example too.

One knock-on: this app code is shared with dfxprd, which wasn't in the original (dfxdev-only) scope. To avoid breaking prod once the env var is gone, I also migrated dfxprd in the infra PR (mount the live cert + set the path env on the prod dfx-api/lds-api services). See DFXServer/server#366.

[github-actions]

⚠️ Unverified Commits (1)

The following commits are not signed/verified:

• 49ac77e Read LND cert from file only, drop env-var fallback (Danswar)

How to sign commits

# SSH signing (recommended)
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

# Re-sign last commit
git commit --amend -S --no-edit
git push --force-with-lease

[davidleomay]

Approved. Deploy after server PR (DFXServer/server#366) — that adds the cert mount + LIGHTNING_API_CERTIFICATE_PATH env var.

[Danswar]

Small refinement after CI: readCert() only throws when LIGHTNING_API_CERTIFICATE_PATH is set but unreadable (your point — no silent fallback on a broken mount). When the path is unset it returns undefined instead of throwing, because Configuration is built eagerly at import and a hard throw broke every test suite that loads config (CI sets no Lightning env). Net effect is the same in real deploys (path is always set via compose); this just keeps non-Lightning environments (tests/CI) bootable. CI green now.