Why this happens
RDS for PostgreSQL 15 and later ships with therds.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 encryptionin the message means the client connected without TLS. This is the common case.SSL encryptionmeans 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’sallowed_security_group_ids/allowed_cidr_blocks. The TLS fixes below do not apply to this variant.
Fix: require TLS in the connection string
For theno encryption variant, add sslmode=require to the connection URL, or the equivalent driver option:
- Node (pg, Prisma, Drizzle)
- Rails
- Django
- Go (pgx)
node-postgres honours sslmode=require in the URL. Or in code:?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
Forsslmode=verify-full, the client needs the RDS certificate authority bundle. Download the global bundle from AWS and mount or bake it into the image:
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, setrds.force_ssl to 0 in the module’s parameter group:
ravion.yaml