I want to check from my server, if the SSL certificate is valid on another server/domain. Is there any way how I can check this?
I think I need to use the https API from NodeJS, but I'm not sure.
When you make an SSL request from NodeJS using its https library, it will take care of the job of verifying the validity of the server it's contacting.
From NodeJS doc:
rejectUnauthorized: If true, the server certificate is verified
against the list of supplied CAs. An 'error' event is emitted if
verification fails. Verification happens at the connection level,
before the HTTP request is sent. Default true
Further more, you can assert the res.socket.authorized attribute in the response:
var https = require('https');
var options = {
host: 'google.com',
method: 'get',
path: '/'
};
var req = https.request(options,
function (res) {
console.log('certificate authorized:' + res.socket.authorized);
});
req.end();
You can also use res.socket.getPeerCertificate() to get detailed information on the server certificate.
Related
I am using the node js HTTP-Proxy module to proxy requests to domain. When I use the module to proxy requests as below I get an SSL error
httpProxy = require('http-proxy'),
fs = require('fs');
process.env['NODE_TLS_REJECT_UNAUTHORIZED'] = 0;
httpProxy.createServer({
ssl: {
key: fs.readFileSync('key.pem', 'utf8'),
cert: fs.readFileSync('certificate.pem', 'utf8')
},
target: 'https://company.com',
secure:false
// Depends on your needs, could be false.
}).listen(443);
This error out
Error: write EPROTO 4548494784:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:../deps/openssl/openssl/ssl/record/rec_layer_s3.c:1544:SSL alert number 80
However when I try to get to the same domain using Request module I get a proper response
app.get('/', (req, res) => request({
uri: 'https://company.com'
}).pipe(res))
This works fine.
This error is only noticed in SSL connection to some domains. I suspect its something in the domain. However I cant understand how Request module could work and the http-proxy module will fail for the same url considering they would be probably be using the same underlying foundation code. If someone can help throw light on where I am going wrong, it would be much appreciated.
I am using nodejs for TLS 1.2 requests to a server, which requires client authentication. This means, that during the inital handshake the client has sign a hash value over random values negotiated between client and server.
In nodejs you have to supply the (e.g. RSA) key or the .pfx/.p12 file along with the according passphrase with the request:
var https = require('https'), fs = require('fs')
var options = {
host: url, path: func, method: 'POST',
pfx: fs.readFileSync('mycert.pfx'),
passphrase: 'mysecret',
secureProtocol: 'TLSv1_2_method'
}
var req = https.request(options, function (res) {
...
In fact you are handing out your signature infrastructure instead of just signing a single item.
Customers don't want that, they insist in usage of Windows Certificate Store for signature, or, even better, use a hardware token (smartcard, HSM) or a remote Key Vault that administers and protocols signature creation.
For this I would need a "sign" callback when the basic TLS handshake is done.
I've seen, that nodejs is using a SecureContext object, which is created by TLS.createSecureContext(). Is it possible to replace this object by your own implementation? What is its functional interface? Has anybody already done that?
Any other ideas?
I created a structure certificates to authenticate client-> server, allowing only certificates recognized by the CA using this step by step: https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html
I checked the authority with openssl, and it returns to me OK the certificate server and client, with the same CA. But by setting the parameter rejectUnauthorized to true on the server, the client can not connect.
Is there any extra parameter should I set up to allow authentication by a certificate that I generated?
---- Edit
On the client side I get the following error: ""ECONNRESET" socket hang up"
I spent a long time digging into a similar issue, and I wrote up this to talk about how to dig into various OpenSSL issues with node.js: http://www.thedreaming.org/2016/09/27/nodejs-ssl/
The short answer, though, is if you need to pass the ca parameter when creating you client connection. If you have the self-signed certificate stored in cert.pem, then the client code looks something like:
var https = require('https');
var fs = require('fs');
var certificate = fs.readFileSync('cert.pem');
var options = {
host: serverHost,
port: 443,
path: '/',
ca: [certificate]
};
https.request(options, function(res) {
res.pipe(process.stdout);
}).end();
I have an endpoint (in any language, let's say Python) that exposes some service as HTTPS using a certificate issued by any widely known and trusted CA, that is
probably included in virtually any browser in the world.
The easiest part is that I can issue TLS requests against this endpoint using Node.js with no further problems.
For security reasons, I would like to check that every time my Node.js issues a TLS request against this HTTPS endpoint, I want to make sure that the certificate being used, is the certificate that I trust, and the one that was requested by my company.
What is the best way to accomplish that?
It sounds like the answer at How to get SSL certificate information using node.js? would be suitable for your needs.
You can use the following code to get your endpoint's certificate then check its fingerprint or hash against what you expect.
var https = require('https');
var options = {
host: 'google.com',
port: 443,
method: 'GET'
};
var req = https.request(options, function(res) {
console.log(res.connection.getPeerCertificate());
});
req.end();
I'm writing a Node.js app that has to request some data from one of our internal APIs. The tricky part is that the server I'm requesting data from has certain limitations:
The request must be made on HTTPS protocol (not HTTP)
The request must be made using a LAN IP address, because the domain name will not work internally
The request must appear to be requesting from the external domain name, because that is what the Virtual Host is setup for.
In order to do this, I'm running a bit of code that looks like this:
var headers = {
Host: externalHostname,
Hostname: externalHostname,
};
var options = {
host: InternalIP,
path: path,
method: 'GET',
headers: headers
};
var req = https.request(options, function(res) {
res.setEncoding('utf8');
var data = "";
res.on('data', function(chunk) {
data += chunk;
});
res.on('end', function() {
//Do something with that data
});
res.on('error', function(err) {
console.log("Error during HTTP request");
console.log(err);
});
});
req.end();
Unfortunately, I'm getting a 400 (Your browser sent a request that this server could not understand) error as a response. I've double and triple checked that the hostname, ip address, and path name are all correct (I can test them from within my browser, and all is good).
I did an output of my response variable (res), and am receiving an authorizationError value of UNABLE_TO_VERIFY_LEAF_SIGNATURE. I'm not sure what that is, or if it's my problem, but it's the only useful bit of information I could find.
I put a full output of my response variable here.
Any ideas on what might be causing this?
Update: I figured it out! I was trying to authenticate with the server by passing a ?PHPSESSID=asdad GET variable, but they have that disabled. I was able to make it work by setting PHPSESSID in the Cookie header.
set this process.env['NODE_TLS_REJECT_UNAUTHORIZED'] = '0';
I hit here while debugging UNABLE_TO_VERIFY_LEAF_SIGNATURE error in an external api call from my nodejs server.
This error is hit when there is error during verification of the server certificate. While it is not recommended to disable the security by the following code (which is also available as another answer), it helps to verify if you are chasing the right bug. In other words, if putting this also does not fix it, there is something else wrong with the code.
process.env['NODE_TLS_REJECT_UNAUTHORIZED'] = '0';
In my case, there was silly bug & request was going to localhost itself. Even after putting the above, request failed and that helped me uncover the bug.
Having said that, it is not recommended to use this as a solution. Rather figure out how you can provide additional certificates by setting agent:false & ca:[fs.readFileSync('root-cert.pem')] options. https.request documentation provides details. While chasing my bug, I also found few more useful resources:
ssl-tools.net site provides root & intermediate certificates. For example: Baltimore CyberTrust Root used by lives.api.net
ssl-root-cas module claims to provide additional CA certificates as used by popular browsers. I have not verified the claim.
openssl s_client -connect apis.live.net:443 -- prints the certificate chain. you need to replace the last parameter (url & port) with what you are connecting to.
check this out from the tls.js source in the latest node.js (there is much more this is what I think you need)
// AUTHENTICATION MODES
//
// There are several levels of authentication that TLS/SSL supports.
// Read more about this in "man SSL_set_verify".
//
// 1. The server sends a certificate to the client but does not request a
// cert from the client. This is common for most HTTPS servers. The browser
// can verify the identity of the server, but the server does not know who
// the client is. Authenticating the client is usually done over HTTP using
// login boxes and cookies and stuff.
//
// 2. The server sends a cert to the client and requests that the client
// also send it a cert. The client knows who the server is and the server is
// requesting the client also identify themselves. There are several
// outcomes:
//
// A) verifyError returns null meaning the client's certificate is signed
// by one of the server's CAs. The server know's the client idenity now
// and the client is authorized.
//
// B) For some reason the client's certificate is not acceptable -
// verifyError returns a string indicating the problem. The server can
// either (i) reject the client or (ii) allow the client to connect as an
// unauthorized connection.
//
// The mode is controlled by two boolean variables.
//
// requestCert
// If true the server requests a certificate from client connections. For
// the common HTTPS case, users will want this to be false, which is what
// it defaults to.
//
// rejectUnauthorized
// If true clients whose certificates are invalid for any reason will not
// be allowed to make connections. If false, they will simply be marked as
// unauthorized but secure communication will continue. By default this is
// false.
//
set rejectUnauthorized to false in your options and cross your fingers...let me know if the output changes.
Set this process.env['NODE_TLS_REJECT_UNAUTHORIZED'] = '0';
Fixed the UNABLE_TO_VERIFY_LEAF_SIGNATURE problem for superagent.
Try this in command line:
npm config set strict-ssl false
It worked for me on mac.