Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

how to handle SSL #76

Open
dagda1 opened this issue Jun 14, 2021 · 2 comments
Open

how to handle SSL #76

dagda1 opened this issue Jun 14, 2021 · 2 comments

Comments

@dagda1
Copy link
Contributor

dagda1 commented Jun 14, 2021

Dealing with self-signed SSL certificates for localhost development is a tricky business. We also want to leave the door open to allow users to point to real SSL certificates if, for example, a simulator is running in the cloud.

We have currently left in a short term solution of using the node environment variable NODE_EXTRA_CA_CERTS to point to the CA cert but this is not a good long term solution.

  • NODE_EXTRA_CA_CERTS="$(mkcert -CAROOT)/rootCA.pem" mocha -r ts-node/register --timeout 10000 test/**/*.test.ts"

This is bad because it implies the user has used mkcert to install their certs.

The self-signed certificates need to be trusted in 2 main scenarios so far:

  • browser
  • node

Both are slightly different and have different challenges for localhost development.

In the case of the auth0 simulator and when dealing with SPAs that use such trickery as webworkers and hidden iframes then the SSL needs to be trusted or else the browser will (with good reason) disable new-age voodoo tools like webworkers.

For node, the SSL and TLS packages need to be able to ascertain a full chain of trust from the certificate back to the local CA self-signed cert.

We have used mkcert which for the most part has worked and covers off the browser case quite nicely.

It does not cover the node case as it does not create a full chain or an intermediary certificate, see this issue for background.

This leaves us with the following options

  • use process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0"; which is a nuclear approach to just tell node to ignore all certificate issues. As bad as this seems, it does have benefit of being simple and we are dealing with a fake simulator so do we really need it to be totally real?
  • Do what we are currently doing and set NODE_EXTRA_CA_CERTS where appropriate
  • Create proper self signed certs using openssl that behave as normal. here is a good post about certificate chains.
  • Monkey patch SecureContext.

We also need to be able to configure a simulator to point to other certs when not running in localhost.

@cowboyd
Copy link
Member

cowboyd commented Jun 23, 2021

I'm not sure I understand the problem. If we did the work to generate a certificate chain, what would it look like, and how would node TLS be able to verify it without adding an extra CA to the NODE_EXTRA_CA_CERTS variable?

I thought the problem was that node never looks at system certificate authorities, but only at those that it comes bundled with.

@dagda1
Copy link
Contributor Author

dagda1 commented Jun 24, 2021

I thought the problem was that node never looks at system certificate authorities, but only at those that it comes bundled with.

This is correct, node uses a hardcoded list of certificate authorities.

I created the issue to check we are happy that setting NODE_EXTRA_CA_CERTS is the best way of handling this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants