fix(db): drop inlined RDS CA bundle (fixes staging P1011 TlsConnectionError) - #2775
Merged
Merged
Conversation
URGENT: production runtime fix. Staging is hitting: Error [PrismaClientKnownRequestError] Invalid `prisma.member.findFirst()` invocation Error opening a TLS connection: unable to get local issuer certificate code: 'P1011', driverAdapterError: TlsConnectionError Cause: PR #2772 set `ssl.ca = RDS_CA_BUNDLE` in the prisma adapter, which *replaces* Node's trust store rather than augmenting it. Our bundle only contains the 108 RDS-specific regional self-signed CAs — it does NOT contain Amazon Root CA 1, which is where AWS RDS Proxy chains terminate (and which lives in Node's default Mozilla bundle). So the chain failed to validate at runtime under the strict-TLS branch. Why apps/app and apps/portal didn't trip this in earlier checks: - The /auth route returned 200 because that codepath doesn't query the DB; it talks to apps/api over HTTP, and apps/api uses a different prisma client (Docker, NODE_EXTRA_CA_CERTS at OS level). - DB-touching SSR routes (e.g., /[orgId]/overview) are exactly what the reported staging failure exercises. Fix: drop the `ca:` field. Node's default trust store includes Amazon Root CA 1, which is sufficient for chain validation against RDS Proxy. Hostname check is still skipped (NLB topology — chain check still rejects forged or wrong-CA certs). PRISMA_ALLOW_INSECURE_TLS=1 remains the explicit insecure opt-out — the original Cubic finding fix is preserved. Files: - packages/db/src/ssl-config.ts: drop RDS_CA_BUNDLE import + usage - packages/db/src/client.test.ts: rewrite tests for new behavior (6 pass) - apps/{app,portal,framework-editor}/prisma/client.ts: drop the ca: branch - Delete: packages/db/{certs/rds-global-bundle.pem,src/rds-ca-bundle.ts, scripts/generate-ca-bundle-ts.mjs} and the inlined rds-ca-bundle.ts copies in apps/{app,portal,framework-editor}/prisma/ (~660KB removed) - packages/db: 2.2.0 → 2.3.0 (also drops `certs` from `files` array) - apps/api/prisma/client.ts: unchanged — Docker still uses NODE_EXTRA_CA_CERTS at OS level and that path is fine. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Contributor
|
🎉 This PR is included in version 3.44.2 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Production runtime fix. Staging is currently 500-ing on DB-touching SSR routes (e.g. `/[orgId]/overview`) with:
```
Error [PrismaClientKnownRequestError]
Invalid `prisma.member.findFirst()` invocation
Error opening a TLS connection: unable to get local issuer certificate
code: 'P1011', driverAdapterError: TlsConnectionError
```
Cause
PR #2772 set `ssl.ca = RDS_CA_BUNDLE` in the prisma adapter. Node's TLS treats `ssl.ca` as a replacement for the trust store, not an augmentation. Our bundle (`packages/db/certs/rds-global-bundle.pem`) only contains the 108 RDS-specific regional self-signed CAs — it does not contain Amazon Root CA 1, which is where AWS RDS Proxy cert chains terminate (and which lives in Node's default Mozilla bundle).
So under the strict-TLS branch (`isLocalhost ? undefined : allowInsecure ? insecure : { ca: RDS_CA_BUNDLE, ... }`), every non-localhost connection lost access to Amazon Root CA, and chain validation failed.
Why this didn't trip earlier preview-deploy checks: the routes I sampled (`/auth`, `/`) don't actually query the DB from apps/app's prisma client — they talk to apps/api over HTTP, and apps/api runs in Docker with `NODE_EXTRA_CA_CERTS` set at the OS level (a different code path that doesn't go through `ssl.ca`). DB-touching SSR routes like `/[orgId]/overview` are exactly what the reported failure exercises.
Fix
Drop `ssl.ca` entirely. Node's default trust store includes Amazon Root CA 1, which validates the RDS Proxy chain. Hostname check stays skipped (NLB topology — chain check still rejects forged certs). `PRISMA_ALLOW_INSECURE_TLS=1` remains the explicit opt-out, so the original Cubic finding (silent `rejectUnauthorized: false`) stays fixed.
Same shape as comp-private#277.
Files
Test plan
🤖 Generated with Claude Code
Summary by cubic
Fix TLS errors in staging by removing the inlined RDS CA bundle and using Node’s default trust store. Restores DB connectivity for SSR routes while keeping the explicit
PRISMA_ALLOW_INSECURE_TLS=1opt-out.ssl.cafrom Prisma adapters; rely on Node’s trust store (includes Amazon Root CA 1).@trycompai/dbto2.3.0and droppedcertsfromfiles.apps/apiunchanged (Docker usesNODE_EXTRA_CA_CERTS).Written for commit 0b21c8f. Summary will update on new commits.