Open dkebler opened 7 years ago
I do not think this is a redbird specific issue, more like nodejs. Can you verify it works using node TLS server directly?
if you mean, can I visit https://lights.645.kebler.net:8443 directly, yes no problems
under it all redbird uses some nodejs modules to do TLS verification right? Many folks suggest adding a module require('ssl-root-cas').inject(); but that would be to inject real CAs into a node app. This is a self signed cert and I should be able to add my "bogus" personal root CA as I did and get it accepted no???
check this post out. https://stackoverflow.com/questions/31673587/error-unable-to-verify-the-first-certificate-in-nodejs
While you consider this I'll try to get a letsencrypt cert and try that. I assume I don't have to use the ca: option for that?
There is no point really in using self signed certificates since the availability of LE, unless it is for local development or something like that. Just be careful not to be banned, only use the production flag when everything works as expected.
yes it is for a private personal network (mostly development). I would like redbird to work with self-signed certs. Let me try a letsencrypt one. If that works then the issue is redbird with self-signed certs.
ok ended up getting a paid wildcard cert since letencrypt does not offer that
I still had some issues with my code and getting the same error until I tried this. Maybe I could try again with self-signed cert but no time right now.
const proxy = require('redbird')({
port: 80,
ssl: {
port: 443,
key: '/xxx/certs/wc.xxx.net.key',
cert: '/xxx/certs/wc.xxx.net.crt',
ca: '/xxx/certs/wc.xxx.net.ca-bundle'
}
})
console.log ('STARTING REVERSE PROXY')
proxy.register('http://lights.kebler.net', 'http://trantor.kebler.net',{ ssl: true})
Nope....when you proxy to a port other than 443 the errors return :-(.
Entering lights.kebler.net in browser gives
Error
ECONNRESET
with
proxy.register('lights.kebler.net', '192.168.0.1:8443',{ ssl: true})
or
proxy.register('lights.kebler.net', 'http://gateway.kebler.net:8443',{ ssl: true})
----------- OR
error
UNABLE_TO_VERIFY_LEAF_SIGNATURE (unable to verify first certificate)
proxy.register('lights.kebler.net', 'https://gateway.kebler.net:8443',{ ssl: true})
or
proxy.register('lights.kebler.net', 'https://192.168.0.1:8443',{ ssl: true})
and yes if I go to it directly without proxy no issues. The wildcert works fine, green lock. https://gateway.kebler.net:8443
also getting a green lock for lights.kebler.net so doesn't seem a cert issue now.
It seems an SSL proxy to a port other than 443 causes the issue
More info
here i proxy to 443 like so
proxy.register('lights.kebler.net', 'http://trantor.kebler.net',{ ssl: true})
and it's fine but if I do this
proxy.register('lights.kebler.net', 'https://trantor.kebler.net',{ ssl: true})
I get the leaf error
So seems proxy to https just doesn't work period (leaf error) and proxy to port other than 443 resets the connection and dies
I tried the same with redwire module and I get the exact same result. So it's not unique to redbird (i.e. cannot https proxy to https server running on other than port 443). BTW works fine if its being redirected to just an http server at any port so it's just if I am running an https server.
So maybe this is less an issue and more a requested "enhancement" I'm obviously not grokking the underlying https methods and their handshaking/limitations. Maybe this is just not possible (why not?)
Today I run in this. I'm using version 0.2.3
You could use this configuration:
const proxy = require('redbird')({
secure: false,
port: 80,
ssl: {
port: 443
}
})
console.log ('STARTING REVERSE PROXY')
proxy.register('http://lights.kebler.net', 'https://192.168.0.1:8443',{
ssl: true,
key: '/xxx/certs/wc.xxx.net.key',
cert: '/xxx/certs/wc.xxx.net.crt'
})
I have a self singed certificate with my own ca I created.
Despite using doing this
redbird is not not able to verigy my cert given my ca cert.
which leads to this related error in the browser
UNABLE_TO_VERIFY_LEAF_SIGNATURE
does redbird not support personal CAs certs?
if not is there a request option to ignore this check? like strictSSL: false