I have code:
var r = require('request');
r({
method: 'POST',
url: 'https://api.dropbox.com'},
function() { console.log(arguments) } )
When I run it on desktop with Node 0.9.4, I get this in the console:
{ '0': [Error: Hostname/IP doesn't match certificate's altnames] }
When I run it on Netbook with Node 0.6.12, it all works without error (302 response - I think its right).
In question Node.js hostname/IP doesnt match certificates altnames, Rojuinex write: "Yeah, browser issue... sorry". What does "browser issue" mean?
UPD. This problem was resolved after roll back on Node v0.8
ERR_TLS_CERT_ALTNAME_INVALID indicates self signed TLS error.
By setting rejectUnauthorized: false , you're saying "I don't care if I can't verify the server's identity." Obviously this is not a good solution as it leaves you vulnerable to MITM attacks.
Since 0.9.2 (including 0.10.x) node.js now validates certificates by default. This is why you could see it become more strict when you upgrade past node.js 0.8. (HT: https://github.com/mscdex/node-imap/issues/181#issuecomment-14781480)
You can avoid this with the {rejectUnauthorized:false}
option, however this has serious security implications. Anything you send to the peer will still be encrypted, but it becomes much easier to mount a man-in-the-middle attack, i.e. your data will be encrypted to the peer but the peer itself is not the server you think it is!
It would be better to first diagnose why the certificate is not authorizing and see if that could be fixed instead.
A slightly updated answer (since I ran into this problem in different circumstances.)
When you connect to a server using SSL, the first thing the server does is present a certificate which says "I am api.dropbox.com." The certificate has a "subject" and the subject has a "CN" (short for "common name".) The certificate may also have one or more "subjectAltNames". When node.js connects to a server, node.js fetches this certificate, and then verifies that the domain name it thinks it's connecting to (api.dropbox.com) matches either the subject's CN or one of the altnames. Note that, in node 0.10.x, if you connect using an IP, the IP address has to be in the altnames - node.js will not try to verify the IP against the CN.
Setting the rejectUnauthorized
flag to false will get around this check, but first of all if the server is giving you different credentials than you are expecting, something fishy is going on, and second this will also bypass other checks - it's not a good idea if you're connecting over the Internet.
If you are using node >= 0.11.x, you can also specify a checkServerIdentity: function(host, cert)
function to the tls module, which should return undefined
if you want to allow the connection and throw an exception otherwise (although I don't know if request
will proxy this flag through to tls for you.) It can be handy to declare such a function and console.log(host, cert);
to figure out what the heck is going on.
To fix the issue for package http-proxy
1) HTTP (localhost) accessing HTTPS To fix this issue set changeOrigin to true.
const proxy = httpProxy.createProxyServer();
proxy.web(req, res, {
changeOrigin: true,
target: https://example.com:3000,
});
2) HTTPS accessing HTTPS you should include SSL certificate
httpProxy.createServer({
ssl: {
key: fs.readFileSync('valid-ssl-key.pem', 'utf8'),
cert: fs.readFileSync('valid-ssl-cert.pem', 'utf8')
},
target: 'https://example.com:3000',
secure: true
}).listen(443);
The other way to fix this in other circumstances is to use NODE_TLS_REJECT_UNAUTHORIZED=0
as an environment variable
NODE_TLS_REJECT_UNAUTHORIZED=0 node server.js
WARNING: This is a bad idea security-wise
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With