[dev] [Marfuen] mariano/rds-tls-followup

[github-actions]

This is an automated pull request to merge mariano/rds-tls-followup into dev.
It was created by the [Auto Pull Request] action.

---

Summary by cubic

Hardened Prisma TLS for Postgres via RDS Proxy/NLB by combining the RDS CA bundle with Node’s roots and adding a scoped hostname check that only accepts RDS endpoints. Applied across the db package and all app Prisma clients to fix issuer errors without disabling identity verification.

• Bug Fixes

  • Verified TLS: combine RDS_CA_BUNDLE with tls.rootCertificates so direct RDS and Proxy chains validate.
  • Hostname verification: replace no-op with rdsServerIdentity that accepts CN/SAN ending in .rds.amazonaws.com or .rds.amazonaws.com.cn, with full chain validation.
  • Applied in packages/db/src/ssl-config.ts and inlined in apps (api, app, portal, framework-editor); updated tests for resolver and identity checks.

• Dependencies

  • Bump @trycompai/db to 2.2.1.

^{Written for commit fc3b7a3. Summary will update on new commits.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
app	Ready	Preview, Comment	May 6, 2026 9:23pm
comp-framework-editor	Ready	Preview, Comment	May 6, 2026 9:23pm
portal	Ready	Preview, Comment	May 6, 2026 9:23pm

[cubic-dev-ai]

1 issue found across 6 files

Confidence score: 2/5

• I’m scoring this as high risk because the issue is security-relevant (severity 6/10, confidence 7/10): TLS identity verification in apps/api/prisma/client.ts appears too permissive rather than strict.
• The custom checkServerIdentity behavior could allow trusting any AWS RDS certificate without confirming it matches the intended endpoint host, which weakens hostname validation and increases MITM/regression risk.
• This is likely merge-blocking until tightened, since certificate-host binding is a core transport security control for database connections.
• Pay close attention to apps/api/prisma/client.ts - ensure checkServerIdentity validates the certificate identity against the exact target host, not just AWS RDS affiliation.

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/api/prisma/client.ts">

<violation number="1" location="apps/api/prisma/client.ts:21">
P2: The custom `checkServerIdentity` is too permissive: it accepts any AWS RDS certificate and does not bind certificate identity to the intended endpoint host.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review, or fix all with cubic.}

[cubic-dev-ai]

P2: The custom checkServerIdentity is too permissive: it accepts any AWS RDS certificate and does not bind certificate identity to the intended endpoint host.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/api/prisma/client.ts, line 21:

<comment>The custom `checkServerIdentity` is too permissive: it accepts any AWS RDS certificate and does not bind certificate identity to the intended endpoint host.</comment>

<file context>
@@ -1,10 +1,29 @@
+    .split(',')
+    .map((s) => s.trim().replace(/^DNS:/, ''));
+  const cn = (cert.subject as { CN?: string } | undefined)?.CN ?? '';
+  if (isRdsHostname(cn) || sans.some(isRdsHostname)) return undefined;
+  return new Error(
+    `TLS hostname check: cert is not for an AWS RDS endpoint (CN=${cn}, SANs=${sans.join(',')})`,
</file context>

[Marfuen]

Closing — over-engineered. The combine-with-rootCertificates and custom rdsServerIdentity were chasing narrow threat models inside an AWS VPC. The actual Cubic finding (silent rejectUnauthorized: false fallback) was already fixed by #2772. Beyond that, Node's default trust store includes Amazon Root CA 1 which is sufficient for RDS Proxy chain validation. Comp-private PR #276 was simplified accordingly.