prisma: Error: The certificate was not trusted

Hello, I’ve got this error today with latest alpha:

prisma2@2.0.0-alpha.281, binary version: c55e482a7a27ec30ea41b074ffb3de8a1a40c36e

image

PS: I’m with sslmode=prefer and report id 457

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Reactions: 1
  • Comments: 28 (14 by maintainers)

Most upvoted comments

Adding sslaccept=accept_invalid_certs to your datasource url should work for now

@janpio , @pantharshit00

  1. new project, no previous database migrations
  2. postgresql database hosted on DigitalOcean (connection string works fine)
  3. running prisma2 lift save produces the error above

The same three steps with a local postgresql database work fine.

This is fixed upstream, the change should make it in preview 18 😃 More context in https://github.com/prisma/specs/issues/325

I can confirm this bug in prisma2@2.0.0-preview016, binary version: 377e2db71bae5da19d0090558c8819ff57dfdfc6

image

Thanks for the reproduction steps @iherger 😃

@janpio Could we get a clarification on this?

I have just tried this approach:

  1. Setup local environment with a Prisma schema pointed to the local DB and run the prisma2 generate – works without any problem
  2. Prepare new Postgress on Heroku and change the link in the local schema to the remote one and call again the prisma2 generate (on my local) – seen the error
  3. Fixed the postgress URL by the parameter: sslaccept=accept_invalid_certs and call the command again – now it works fine, the remote database were generated.

So IMHO the problem is still there

Encountering the same issue with a postgres database hosted on heroku. Adding sslaccept=accept_invalid_certs to the connection url fixed it.

Yes, we implemented passing custom certificates for postgres connections a few weeks ago and I think that’s when the decision was made.

I spent a lot of time investigating this, and the conclusion is that what we are doing is not buggy, but much stricter than most other postgres clients. We will relax the current behaviour a bit (otherwise you would have to pass certificate files to the postgres connection in nearly every scenario). I will keep this issue up to date.