Skip to main content
Your app fails to connect to RDS with an error like one of these:

Why this happens

RDS for PostgreSQL 15 and later ships with the rds.force_ssl parameter set to 1, so the server rejects connections that do not negotiate TLS. Older major versions default to 0, which is why an app that worked against Postgres 13 or 14 breaks after an upgrade or a fresh instance.
  • no encryption in the message means the client connected without TLS. This is the common case.
  • SSL encryption means TLS was negotiated and the rejection is about the user, database, or source: check the username and database in the connection string, and that the task’s security group or CIDR is in the RDS module’s allowed_security_group_ids/allowed_cidr_blocks. The TLS fixes below do not apply to this variant.
Both are client-side configuration problems, not network problems. If the app could not reach the instance at all you would see a connection timeout instead.

Fix: require TLS in the connection string

For the no encryption variant, add sslmode=require to the connection URL, or the equivalent driver option:
node-postgres honours sslmode=require in the URL. Or in code:
Prisma: append ?sslmode=require to DATABASE_URL. Drizzle: pass ssl: "require" to the driver.
sslmode=require encrypts the connection but does not verify the server certificate. That is acceptable inside a VPC, and it is what most managed platforms use.

Fix: verify the server certificate

For sslmode=verify-full, the client needs the RDS certificate authority bundle. Download the global bundle from AWS and mount or bake it into the image:
The rvn-rds module’s ca_cert_identifier input selects which RDS CA signs the instance certificate; the global bundle covers all of them. See the AWS documentation on SSL for RDS.

Alternative: turn off the requirement

If a client cannot do TLS at all, set rds.force_ssl to 0 in the module’s parameter group:
ravion.yaml
This weakens the security of traffic inside your VPC — prefer fixing the client.