gatsby: Regression: self-signed certificates no longer work
Description
I’m having a hard time sorting out what package version where causes the issue, but when upgrading from gatsby 2.9.8 to 2.9.9 I now get this error when starting gatsby with a self-signed certificate:
error UNHANDLED REJECTION
FetchError: request to https://localhost:8002/___graphql failed, reason: self signed certificate
- index.js:1455 ClientRequest.<anonymous>
[hello-epics]/[node-fetch]/lib/index.js:1455:11
- destroy.js:82 emitErrorNT
internal/streams/destroy.js:82:8
- destroy.js:50 emitErrorAndCloseNT
internal/streams/destroy.js:50:3
- next_tick.js:63 process._tickCallback
internal/process/next_tick.js:63:19
My guess is it has to do with the upgrade of node-fetch in gatsby-cli
Steps to reproduce
Create and trust ssl certificates, then run gatsby using them. I’ve also tried with the auto generated certificates and I get a different error.
gatsby develop --port 8002 --https --key-file ../config/localhost/key.pem --cert-file ../config/localhost/cert.pem
Expected result
It should start gatsby
Actual result
error UNHANDLED REJECTION
FetchError: request to https://localhost:8002/___graphql failed, reason: self signed certificate
- index.js:1455 ClientRequest.<anonymous>
[hello-epics]/[node-fetch]/lib/index.js:1455:11
- destroy.js:82 emitErrorNT
internal/streams/destroy.js:82:8
- destroy.js:50 emitErrorAndCloseNT
internal/streams/destroy.js:50:3
- next_tick.js:63 process._tickCallback
internal/process/next_tick.js:63:19
Environment
Run gatsby info --clipboard in your project directory and paste the output here.
System:
OS: macOS 10.14.5
CPU: (8) x64 Intel(R) Core(TM) i7-7920HQ CPU @ 3.10GHz
Shell: 5.6.2 - /usr/local/bin/zsh
Binaries:
Node: 10.15.3 - /var/folders/p4/0ptjct956432wm2q1dd048g40000gn/T/yarn--1561063929532-0.7049991999729923/node
Yarn: 1.16.0 - /var/folders/p4/0ptjct956432wm2q1dd048g40000gn/T/yarn--1561063929532-0.7049991999729923/yarn
npm: 6.4.1 - ~/.asdf/shims/npm
Languages:
Python: 2.7.15 - /usr/local/bin/python
Browsers:
Chrome: 75.0.3770.100
Firefox: 67.0.3
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 9
- Comments: 26 (15 by maintainers)
Still broken.
Be gone gatsbot. Still broken.
So issue today became critical. Chrome stopped allowing
NODE_TLS_REJECT_UNAUTHORIZED=0for me.We have found solution:
navigate to
chrome://flagsin chrome, and switchAllow invalid certificates for resources loaded from localhost.toEnableI have submitted a PR that should fix the problem, but it’s dependent on an upstream PR. Check out #18703. Could be a little while before it gets merged, though, depending on how long we wait for
devcertto merge the PR thereOne issue here is that node is not trusting self-signed certificates. A workaround, for now, is to disable TLS rejection:
If you have a cert signed by a certificate authority, like the automated process uses, then a better, but more complicated, workaround is to add the certificate authority to the trusted roots chain:
The automated process does write your CA cert to disk, in different locations depending on your OS. If you tell me your OS, I can tell you where it will put it, and then you can use that path.
The current package that manages certificates,
devcert-san, is buggy, and the upgraded version has plenty of new bugs, too; and there doesn’t seem to be anybody maintaining it. It also doesn’t provide access to the certificate authority’s cert. I’ve done some checking around for different packages that will fix this, but they all seem to have issues, and very little maintenance. I’m planning on building a small module that should fix the problem; just haven’t had the time to come back to it yet.#18703 is really, really close to being merged. Just waiting on one more review
I wish I understood enough of this thread to get any of the workarounds working 😔
@in-in I’ve never used
mkcertbefore, but it looks pretty cool; looks like its pretty reliable in setting the trust for its CA for you. I can only speak to how I got the trust working correctly in Ubuntu (which shouldn’t differ that much, in this regard, from Mint). It took adding the certificate to~/.pki/nssdb, which I guess is not really specifically Chrome’s nssdb (more like the current user’s trust store). The point is that it wasn’t using the system trust store.It looks like
mkcertstores its CA at$HOME/Library/Application Support/mkcerton MacOS, so you could use the samegatsby developcommand, but pointNODE_EXTRA_CA_CERTSatmkcert’s CA. Assuming node can read the file, that should work without having to allow unauthorized certificates.We are seeing the same issue as of 2.9.9. Using self-signed certs now causes builds to fail.
The workaround in #15043 works, but isn’t a long-term solution.
The workaround is to set this env before running start: