added ability to ignore certificate validation for self signed certificate

[killmenot]

[killmenot]

Also, sometimes auth url can be empty string and it cannot be passed via constructor

[jasonsims]

+1

I would like to see this merged since our dev servers all use self-signed certs

[jasonsims]

bump This looks like a quick addition and includes tests. I'd utilize the fork for the time being but it's a nested dependency of passport-oauth2.

cc: @ciaranj

[ciaranj]

Hmmm, it doesn't seem like a very 'safe' flag to add to the library tbh, it could encourage bad practices that might find their way into production. Is there no other way (for example adding your certificates to the globalAgent ca property?) to manage this in the environment ?

[jasonsims]

Most libraries I've dealt with allow for this for dev purposes. I want to avoid creating certs signed by a legit CA for all dev environments. Your suggestion could also be an option but I'm not sure how to accomplish this. Have you used that method before?

[ciaranj]

Funnily enough I faced a similar issue just the last week. Initially we also self signed each of the developer's machines, however it became (rapidly) apparent that this was a bad plan as when the developers needed to communicate inter-machine the trust model broke down again (obviously!)

To get around this we actually created a shared self signed certificate that we used as a CA certificate, and shared that amongst all the machines and provided a script to generate a certificate signing request against it for each developer. (A more elegant solution would be to have a dedicated CA VM somewhere so you don't have to worry about the issuer_id+serial_id uniqueness issues, but this works for us, for now.)

To get this working in node, rather than each developer having to trust their specific certificate we just then had to convince node to trust the shared CA certificate (chain of trust ensures that the developer specific certificates werer then trusted.) To do this we used this package: https://www.npmjs.org/package/ssl-root-cas (which is effectively syntactic sugar around manipulating the https.globalAgent.options.ca property.)

This approach gave me confidence there was no chance of an accidental "don't verify SSL" choice hitting production whilst minimising developer pain when accessing each other's 'secured' resources.

Might something similar work for you ?

[jasonsims]

I accidentally deleted my previous comment so I'm hoping you received it in email. If you did can you paste it back in this thread to preserve the history? However, I tried that out what I had described and it failing though. I don't think the ssl-root-cas strategy will work in this scenario.

*Edit: * I was able to recover a version of the previous comment so I'm including it below

This could potentially work. So the current environment is: => app1: identity server using self-signed cert running on port 9443 => app2: node server with passport running on port 1337 with this dependency tree

app
|-- node_modules/
|---- passport/
|---- passport-customstrategy/
|------ node_modules/
|-------- passport-oauth2/
|---------- node_modules/
|------------ oauth/

In my case, app2 authenticates via the OAuth2 flow against app1. However, since app1 has a self-signed cert, the flow currently fails with the UNABLE_TO_VERIFY_LEAF_SIGNATURE error. If I understand it correctly, your solution would have app2 use ssl-root-cas during bootstrap in order to trust the self-signed cert of app1.

// app2
//-------
// appBootstrap.js
require('ssl-root-cas')
  .inject()
  .addFile(__dirname + '/ssl/app1-server.crt')

Can you confirm this is what you meant? I'm still not fully clear on how what I setup by requiring ssl-root-cas in my app gets utilized by the OAuth2._request call executed by the nested node-oauth dependency.

[ciaranj]

yes, that's pretty much exactly what i meant :)

[jasonsims]

Alright, if I could get that to work it would be a suitable solution. It's not working for me right now though and I'm still getting the leaf signature error. Instead of using ssl-root-cas I just did:

// .crt file is of the form
//
// ----BEGIN CERTIFICATE-----
// sMzOM4asB2iltr2QKozni5aVFu818MpOLZIr8LMnTzWllJvvaA5RAAdpbECb+48FjbBe0hseUdN5
// ...
// sMzOM4asB2iltr2QKozni5aVFu818MpOLZIr8LMnTzWllJvvaA5RAAdpbECb+48FjbBe0hseUdN5
// -----END CERTIFICATE-----
//
var https = require('https')
var cas = https.globalAgent.options.ca || []
cas.push(fs.readFileSync('./ssl/wso2is-dev.crt').toString())
https.globalAgent.options.ca = cas

[jasonsims]

I'm still having issues with the suggestion. I created my own self-signed rootCA cert using

openssl genrsa -out rootCA.key 2048
openssl req -x509 -new -nodes -key rootCA.key -days 365 -out rootCA.crt

Then added it into the list of trusted CAs with ssl-root-cas with

require('ssl-root-cas/latest')
  .inject()
  .addFile('./ssl/rootCA.crt')

This solved the UNABLE_TO_VERIFY_LEAF_SIGNATURE error but introduced a new one. @ciaranj, how were you able to successfully add a self-signed root cert to the root CAs? When I do this, the HTTPS request errors out with SELF_SIGNED_CERT_IN_CHAIN.

[tscolari]

For anyone looking for this, an insecure but working solution is:

require('https').globalAgent.options.rejectUnauthorized = false

[DDuarte]

As of Node 7.3, env var NODE_EXTRA_CA_CERTS can be used as an alternative to changing https.globalAgent.options.ca in code.

export NODE_EXTRA_CA_CERTS='path/to/ca.pem'