app DB pool disables certificate verification (ssl.rejectUnauthorized false) - encrypted but unverified, and the fix needs DATABASE_URL's real host first
MEASURED, not inferred. app/src/lib/db.ts:32 builds its Pool with ssl: { rejectUnauthorized: false } on pg ^8.22.0. That is NOT terra's case: terra's src/db/pool.ts has no ssl object at all, and node-postgres with no ssl config negotiates no TLS, so terra is cleartext. Enamel passes an ssl object, so the app's connection IS encrypted - the residual here is NO CERTIFICATE VERIFICATION, which is the same gap just closed on ENAMEL_OUTBOX_DSN and is a weaker finding than cleartext. Do not let the fleet sweep record enamel's app as cleartext; it is not. WHAT IS ALREADY PROVEN: /home/rob/.config/postgres/prod-ca-2021.crt validates aws-1-sa-east-1.pooler.supabase.com:5432 under sslmode=verify-full from venus, and the control was forced to fail (a bad sslrootcert path refuses the connection outright), so verify-full is enforced there rather than silently accepted. WHAT BLOCKS THE APP-SIDE FIX AND IS THE ONLY OPEN QUESTION: I cannot read DATABASE_URL. Vercel holds it write-only - vercel env pull returns it as a value while CRON_SECRET and the SMTP trio come back as empty strings, but I have not re-read it this session and must not assume the host. verify-full checks the HOSTNAME too, so if the app connects through the transaction pooler (:6543) or a different host than the one the CA was verified against, shipping ssl: { ca } turns every query in production into a connection error at once. That is the whole blast radius: db.ts is the single pool for the entire app. DO NOT SHIP BLIND. Sequence: (1) establish which host+port DATABASE_URL actually names; (2) verify that exact endpoint from venus with psql sslmode=verify-full and the same CA, forcing the bad-CA control to fail; (3) only then replace rejectUnauthorized: false with ssl: { ca: <bundled cert>, rejectUnauthorized: true } and bundle the CA into the deployment; (4) push and confirm a real query path, not a build success - a bad cert fails at CONNECT time, so a green build proves nothing.
Activity
-
Pushed 026f959, app v0.10.13. poolSslConfig() pins the Supabase Root 2021 CA with rejectUnauthorized:true, replacing ssl:{rejectUnauthorized:false} (encrypted but zero certificate check). CA inlined rather than fs.readFileSync: bundler tracing into a lambda is a build-time decision nothing asserts and its failure mode is a green build with every connection dying at CONNECT. Measured against aws-1-sa-east-1.pooler.supabase.com:6543 with node-postgres configured exactly as db.ts now configures it - live CONNECTED, control A junk CA REFUSED with SELF_SIGNED_CERT_IN_CHAIN, control B by-IP REFUSED with ERR_TLS_CERT_ALTNAME_INVALID. 5 unit tests in app/src/lib/__tests__/db-tls.test.ts pin the config, since broken and fixed are behaviourally identical until someone is in the middle of the connection. Gate: 1 pre-existing warning 0 errors, 8 files / 229 tests passed. Deploy verification pending.
-
Deploy verified on a REAL query path, not a green build. dpl_7HLBqNvN17ctsVir7QjBmvCuMkxz, GET https://enamel-evolutiva.pensanta.com/api/health -> 200 {version:0.10.13, dbOk:true}. That is the decisive check: a certificate failure surfaces at CONNECT time, so dbOk:true from a lambda running rejectUnauthorized:true against the transaction pooler proves the chain AND hostname verified, and simultaneously proves the inlined CA was bundled (the readFileSync failure mode this avoided would have built green and died at CONNECT). ENAMEL-46 done.
-
completed