prisma: `npx prisma` results in self-signed cert error, though npm config cafile is properly set

Actually, one of my teammates pointed out that if I set the environment variable NODE_EXTRA_CA_CERTS to the path to my .pem file, then npx prisma migrate works as intended.

Run this before: set NODE_TLS_REJECT_UNAUTHORIZED=0

I can confirm that setting NODE_EXTRA_CA_CERTS worked for me as well. No need to download the library/engines and reference them locally.

That also solved my schemaPush error mentioned above, presumably because of utilizing the wrong engine as you mentioned @janpio. As that is no longer an issue, I’m not going to worry about opening up a new ticket as it was likely operator error (i.e. downloading the wrong engine versions).

For reference, running npx primsa -v produced the following:

#14 [prisma 10/10] RUN npx prisma -v
#14 sha256:c88b2b833af52b261ba1ca07ea3defc07ee0d9bff9ce727037e672a9e7611d33
#14 1.887 prisma                  : 3.8.1
#14 1.887 @prisma/client          : 3.8.1
#14 1.887 Current platform        : debian-openssl-1.1.x
#14 1.887 Query Engine (Node-API) : libquery-engine 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/@prisma/engines/libquery_engine-debian-openssl-1.1.x.so.node)
#14 1.887 Migration Engine        : migration-engine-cli 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/@prisma/engines/migration-engine-debian-openssl-1.1.x)
#14 1.887 Introspection Engine    : introspection-core 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/@prisma/engines/introspection-engine-debian-openssl-1.1.x)
#14 1.887 Format Binary           : prisma-fmt 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/@prisma/engines/prisma-fmt-debian-openssl-1.1.x)
#14 1.887 Default Engines Hash    : 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f
#14 1.887 Studio                  : 0.452.0

Looks like the commit SHAs for all of those are 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f, whereas the ones I had been downloading were 7d77a7cd570c9dedb4cdf31a1cbec615cf2e1eda. The reason I did this was because there wasn’t a corresponding 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f commit/download for the query library, and I assumed the library and engines would benefit from being from the same commit. I guess a bad assumption. If a user is forced into downloading and referencing the query library and other engines locally, some documentation on how to choose the “right” versions could be useful.

Anyways – thanks @eric79 for opening the thread and providing a solution! (and thanks @janpio for the feedback as well!)

Having this same issue. Came across this other ticket where someone was having an issue with a self-signed cert in the chain.

From @janpio’s comment on that thread, it appears that the engines can be downloaded manually and then paths to those engines can be set via env vars (some documentation is here about it as well).

But unfortunately, after downloading the 4x engines and 1x library, I’m still hitting a snag, but I think it has to do with me not using Docker correctly (that’s where our prisma scripts are actually run).

Here are the engines/libraries that I’ve downloaded specifically, if that helps:

• Query Library
• Query Engine
• Introspection Engine
• Migration Engine
• “Fmt Binary”

I’ll update once I get my Docker stuff figured out to say whether or not downloading/using these binaries as suggested worked or not.

I set the npm cafile like so:

npm config set cafile "C:\\path\\to\\cafile.pem"

I haven’t personally used a tool to re-sign TLS traffic, but these look promising: https://www.netresec.com/?page=PolarProxy https://geekflare.com/ssl-test-certificate/

I don’t understand where can I get this .pem certificate from. Have the same issue.

@vitjaz , this .pem file would be specific to your organization and their local certificate authority that issues certificates used to resign TLS traffic as it crosses the boundary to your organization through the proxy. Perhaps someone else at your organization would know where to find that .pem file?

I turned this into two issues on our side as well:

1. A documentation one at https://github.com/prisma/docs/issues/2996
2. A feature one at https://github.com/prisma/prisma/issues/12457

Is NODE_EXTRA_CA_CERTS equivalent to the solution that was suggested before? Is it normal that only the env var works with Node based tooling, and not the other one or is this something Prisma got wrong?

I believe this is the normal behavior and prisma is working properly. It just wasn’t an obvious step for those of us who are not experts in running applications in the node ecosystem. Maybe it will just be good that this issue is out there so future users having similar issues can find it.

I will close the issue.