Using Node JS TLS passphrase and cipher options when creating a server and client using elliptic curve keys (no shared cipher suites error) - node.js

In relation to this question, I am trying to start a TLS server in node.js to reflect the one I created in OpenSSL. I have tested the client and server using OpenSSL from the command line and they successfully make a connection. When I try to port the server to node.js (and still connect to it with an OpenSSL client), I receive a 'no shared cipher' error. I am wondering if there is something special I need to do when using the passphrase option with tls.createServer()
Below are my successful OpenSSL commands for server and client respectively, note that the passphrase.txt file contains a single line that is the passphrase:
$ openssl s_server -accept 8888 -cert server.cert -key server.key -pass file:passphrase.txt -CAfile ca.cert
$ openssl s_client -connect 127.0.0.1:8888 -cert client.cert -key client.key -pass file:passphrase.txt -CAfile ca.cert
I can also make a successful connection if I specify a cipher for the client and/or server with the additional argument of -cipher 'ECDHE-ECDSA-AES128-GCM-SHA256'. I am using elliptic curve keys generated with openssl ecparam and signed with a CA created using openssl ca as discussed in my previous question.
The server code written in node.js looks like this:
var tls = require('tls');
var fs = require('fs');
var msg = '***********\n\nHello there secure client!\n\n***********';
var port = 8888;
var host = 'localhost';
var options = {
cert : fs.readFileSync('server.cert'),
key : fs.readFileSync('server.key'),
passphrase : (fs.readFileSync('passphrase.txt')).toString(),
ca : fs.readFileSync('ca.cert'),
// ciphers: 'ECDHE-ECDSA-AES128-GCM-SHA256',
// requestCert : true,
// rejectUnauthorized : true
};
tls.createServer(options, function(cleartextStream) {
if (cleartextStream.authorized) {
console.log('Server-side connection authorized by a Certificate Authority.');
} else {
// TODO this code does not appear to get executed even on failed connections
console.log('Server-side connection not authorized: ' + cleartextStream.authorizationError);
}
// send the server message to the client
cleartextStream.write(msg);
cleartextStream.setEncoding('utf8');
cleartextStream.pipe(cleartextStream);
}).listen(port, function() {
console.log('Server started on port: ' + port);
}).on('clientError', function(err){
console.log('A failed client connection attempt occurred.');
console.error(err);
console.log();
});
After calling the above code with node tlsServer.js and attempting to connect with an OpenSSL client on the command line, I receive the following messages.
SERVER:
$ node tlsServer.js
Server started on port: 8888
<< client started here >>
A failed client connection attempt occurred.
[Error: 6396:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:openssl\ssl\s3_srvr.c:1132:
]
CLIENT:
$ openssl s_client -connect 127.0.0.1:8888 -cert client.cert -key client.key -pass file:passphrase.txt -CAfile ca.cert
CONNECTED(00000003)
2674688:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 320 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
I am using node v0.6.15. And the errors do not change when I uncomment the ciphers, requestCert, and rejectUnauthorized in the options list sent to tls.createServer(). I also have a node.js cersion of the client, and I get a socket hang up code ECONNRESET when I attempt to connect to the node server, and the following error when trying to connect to a OpenSSL server:
Connection to localhost:8888 could not be made.
[Error: 6968:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:openssl\ssl\s23_clnt.c:602:
]
Thanks in advance for your help and ideas!

If the passphrase is wrong, maybe. Try removing it.
However, no_shared_cipher is an error raised when the client can't agree on a cipher suit with the server . Try first removing the cipher suit restriction on the server and seeing what it negotiates to use to isolate the problem. If this works, then place one with the client and see what happens.
Also, can you check that node is using the same openssl library as the openssl command.

Related

openssl certificate error for WinRM connection

I have on Windows server certificate which is valid and active and WinRM listener is active as well on port 5986 (telnet works) for WinRM connection that needs to be established from the Linux server.
I didn't copy that certificate anywhere on the linux server as I do not know where that should be or how it should be configured.
If I try to establish WinRM connection I am getting this error on the Linux server.
openssl s_client -connect 10.7.147.210:5986
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 1367 bytes and written 447 bytes
Verification error: unable to verify the first certificate
I tried by referencing CAfile and CApath and cert option but without success:
openssl s_client -cert winrmcert.pem -key winrmcert.key -CApath . -connect 10.7.147.210:5986
openssl s_client -CAfile winrmcert.pem -connect 10.7.147.210:5986
Can you please help me what I need to do and configure on Linux server for certificate generated on Windows server for WinRM connection? I am not the expert for this topic so I would appreciate all useful instructions. Thank you

Node.js won't load Let's Encrypt certificates

https_options:
{ key: '/etc/letsencrypt/live/mywebsite.com/privkey.pem',
cert: '/etc/letsencrypt/live/mywebsite.com/fullchain.pem' }
I just do https.createServer with the above options and get this error:
_tls_common.js:134
c.context.setCert(cert);
^
Error: error:0909006C:PEM routines:get_name:no start line
at Object.createSecureContext (_tls_common.js:134:17)
at Server.setSecureContext (_tls_wrap.js:1017:27)
at Server (_tls_wrap.js:897:8)
at new Server (https.js:61:14)
at Object.createServer (https.js:84:10)
at startWWW (myserver.js:192:9)
I tested the key/cert pair like this: (as others suggested in other questions, blog posts, forum threads)
openssl x509 -text -in /etc/letsencrypt/live/mywebsite.com/fullchain.pem
openssl rsa -text -in /etc/letsencrypt/live/mywebsite.com/privkey.pem
Both commands printed multiple lines of seemingly valid output.
lsb_release -a | grep Description
Description: Ubuntu 18.04.2 LTS
This should fix it:
key: fs.readFileSync('/etc/letsencrypt/live/mywebsite.com/privkey.pem', 'utf8'),
do the same for the cert too .(eg read in utf8 encoding)

NodeJS + Socket.io SSL fails after a few connections

I'm running NodeJS with socket.io, all under SSL. I've recently moved servers and what used to work fine now stops working after a couple of minutes - Chrome says the connection is reset, and curl says there are SSL problems.
I've tried with and without express - neither with any success after a couple of minutes.
So - my minimal code is:
var fs = require('fs');
var https = require('https');
const options = {
key: fs.readFileSync('XXX.key'),
cert: fs.readFileSync('XXX.crt'),
ca: fs.readFileSync('XXX.ca')
};
var app = https.createServer(options, function(req, res) {
res.writeHead(200);
res.end('(not imporant)\n');
}).listen(3000);
var io = require('socket.io')(app);
If I comment out the last line, the server always accepts new connections (albeit without socket.io) and everything works. If I leave that last line in, it works for a minute, various SSL checking tools are all ok, including:
openssl s_client -connect REDACTED.com:3000
CONNECTED(00000003)
depth=3 /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=Hosted by XILO Communications Ltd./OU=PositiveSSL Wildcard/CN=*.REDACTED.com
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
REDACTED
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/OU=Hosted by XILO Communications Ltd./OU=PositiveSSL Wildcard/CN=*.REDACTED.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 5650 bytes and written 456 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: 704A23D4B00B3A445A8C9097427FF26B724458F24B105C847B76E576FCA9C803
Session-ID-ctx:
Master-Key: 04FB6B5B06954516A073C65A456010C819B157A20F5F308EDCC88C8B0FDCD9A990D3A23AC117714363A92EB56BC98272
Key-Arg : None
Start Time: 1474318665
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
But shortly after (and probably a few hundred client connections from people using the site), the same command gives (from a Mac):
CONNECTED(00000003)
65931:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-59.60.1/src/ssl/s23_lib.c:185:
And from linux/vagrant:
CONNECTED(00000003)
140236360926880:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 295 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
curl https://REDACTED:3000 gives:
curl: (35) Unknown SSL protocol error in connection to REDACTED:3000
Does anyone have any ideas how to overcome this? The code works fine on our development machines, but as soon as it goes onto the live servers, it breaks pretty quickly.
Is it anything to do with the fact I'm using a wildcard certificate?
Thanks in advance.
Ed

Certificate verify failed for self signed on Linux 7.2

I have read endless posts on certification error that basically say either turn off validation or fix you certificate. In our project however we really what to use the certificate, but we can't get it to work. The SA and 2 programmers have been try everything we can think of and nothing is working. So clearly we don't know what we are doing.
First, This is the error we get on a simple connection and get perl program. WEBHOSTNAME replace real web hostname.
perl -MIO::Socket::SSL=debug30 testerTut2.pl
DEBUG: .../IO/Socket/SSL.pm:1784: new ctx 46260896
DEBUG: .../IO/Socket/SSL.pm:446: socket not yet connected
DEBUG: .../IO/Socket/SSL.pm:448: socket connected
DEBUG: .../IO/Socket/SSL.pm:466: ssl handshake not started
DEBUG: .../IO/Socket/SSL.pm:501: using SNI with hostname WEBHOSTNAME
DEBUG: .../IO/Socket/SSL.pm:524: set socket to non-blocking to enforce timeout=10
DEBUG: .../IO/Socket/SSL.pm:537: Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:547: ssl handshake in progress
DEBUG: .../IO/Socket/SSL.pm:557: waiting for fd to become ready: SSL wants a read first
DEBUG: .../IO/Socket/SSL.pm:577: socket ready, retrying connect
DEBUG: .../IO/Socket/SSL.pm:1772: ok=0 cert=46303216
DEBUG: .../IO/Socket/SSL.pm:537: Net::SSLeay::connect -> -1
DEBUG: .../IO/Socket/SSL.pm:1408: SSL connect attempt failed with unknown error
DEBUG: .../IO/Socket/SSL.pm:543: fatal SSL error: SSL connect attempt failed with unknown error error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
DEBUG: .../IO/Socket/SSL.pm:1821: free ctx 46260896 open=46260896
DEBUG: .../IO/Socket/SSL.pm:1826: free ctx 46260896 callback
DEBUG: .../IO/Socket/SSL.pm:1829: OK free ctx 46260896
500 Can't connect to WEBHOSTNAME:443 at testerTut2.pl line 34.
This is the perl program:
#!/bin/perl
require LWP::UserAgent;
use LWP::Protocol::https;
#note USERNAME is where the real account name goes
my $ua = LWP::UserAgent->new( ssl_opts => { verify_hostname => 1, SSL_ca_file => '/home/USERNAME/ca-bundle.crt'});
$ua->timeout(10);
$ua->env_proxy;
#note hostname is where the real web host name goes
my $response = $ua->get('https://hostname/tut/ops/data/newtut.dat');
if ($response->is_success)
{
print $response->content;
print $response->decoded_content; # or whatever
}
else
{
die $response->status_line;
}
The SA has made a signed certificate on the web server. Again webhostname would be replaced with real web hostname.
openssl s_client -connect lomweb01:443 -showcerts
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
CONNECTED(00000003)
depth=0 C = US, ST = MD, L = Greenbelt, O = NASA, OU = MMS, CN = webhostname.edtfmmslinux.ecs.nasa.gov
verify error:num=18:self signed certificate
verify return:1
depth=0 C = US, ST = MD, L = Greenbelt, O = NASA, OU = MMS, CN = webhostname.edtfmmslinux.ecs.nasa.gov
verify return:1
---
Certificate chain
0 s:/C=US/ST=MD/L=Greenbelt/O=NASA/OU=MMS/CN=webhostname .edtfmmslinux.ecs.nasa.gov
i:/C=US/ST=MD/L=Greenbelt/O=NASA/OU=MMS/CN=webhostname .edtfmmslinux.ecs.nasa.gov
-----BEGIN CERTIFICATE-----
MIIDbDCCAlQC etc etc k7Pr1nRQG
3/NKQVqaSITGHGZBtlKjpw==
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=MD/L=Greenbelt/O=NASA/OU=MMS/CN=webhostname .edtfmmslinux.ecs.nasa.gov
issuer=/C=US/ST=MD/L=Greenbelt/O=NASA/OU=MMS/CN=webhostname .edtfmmslinux.ecs.nasa.gov
---
No client certificate CA names sent
---
SSL handshake has read 1639 bytes and written 711 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 921941EFFB19FA3158C751D155C012D5A418425BFAE94FEA1D99231A3CEF5D3C
Session-ID-ctx:
Master-Key: 13BFF7BE2B8ED18056BA54415026FC1ED133F47BADE2683A5EB3A2FED15F34ABD3F837985A498404A948B7F5B1F4774B
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - d6 99 6e 28 8c 86 5e 9b-e2 e8 etc. etc.
00b0 - 20 96 ea 05 9
Start Time: 1466432096
Timeout : 300 (sec)
Verify return code: 18 (self signed certificate)
---
On the client box I created a local ca-bundle.crt file in the USERNAME home directory. I "cp /etc/pki/tls/certs/WEBSERVER.crt ~/ca-bundle.crt" and had the perl script set the SSL_ca_file value to its path.
The Apache configuration file was update to use the /etc/pki/tls/cert/WEBSERVER.crt file and restarted.
And it still doesn't work. We have tried different web host name patterns but there is no change. We have no idea why the certificate is not working, but we think we are following the instructions correctly. Firefox is happy after we accept the certificate but perl is not. So what are we doing wrong?
After stracing the perl script it turned out to be sybase. The sybase client comes with an incompatible version of openssl. Net::SSLeay is an interface to openssl. IO::Socket::SSL uses Net::SSLLeay, LWP::UserAgent uses IO::Socket::SSL. When the perl script is run, the PATH has sybase directories in the front. sybase has its own CA files that are not compatible/out of date with the CA RHEL 7 and it reads the sybase CAs first messing everything up by the time it gets to ca.pem. To fix the problem we changed the perl script to strip out the sybase directories from PATH and then the SSL_ca_file option then works fine.
my $ua = LWP::UserAgent->new( ssl_opts => { verify_hostname => 1, SSL_ca_file => '/home/<server account>/certs/ca.pem'});
This is the second sybase side effect we have had since going to RHEL 7. The other one was sybase in increasing file descriptors limits to 4096 vs. the standard 1024 causing a boundary overflow in an array that was hard coded to 1024.

Logstash Forwarder

Trying to send some logs to logstash server. Using logstash forwarder to forward the logs to logstash
But its getting timed out:
2015/03/04 08:19:15.266955 Started harvester at end of file (current offset now 10659): /apps/azuga-dds/logs/amqData.log
2015/03/04 08:19:15.267089 Setting trusted CA from file: /etc/logstash-forwarder/logstash-forwarder.crt
2015/03/04 08:19:15.290016 Connecting to [10.90.9.242]:5000 (ec2-54-70-33-51.us-west-2.compute.amazonaws.com)
2015/03/04 08:19:20.290259 Failure connecting to 10.90.9.242: dial tcp 10.90.9.242:5000: i/o timeout
2015/03/04 08:19:21.291691 Connecting to [10.90.9.242]:5000 (ec2-54-70-33-51.us-west-2.compute.amazonaws.com)
2015/03/04 08:19:26.291903 Failure connecting to 10.90.9.242: dial tcp 10.90.9.242:5000: i/o timeout
2015/03/04 08:19:27.293218 Connecting to [10.90.9.242]:5000 (ec2-54-70-33-51.us-west-2.compute.amazonaws.com)
Any idea how to resolve this issue.
You may have some problems with SSL cert, sometimes checking cert may help. And be sure that you are using same version of JVM on logstash-forwarder, logstash and elasticsearch. Generate cert with your logstash-server IP, log says that you try to connect to host with IP, that not listed in cerificate.
Try
openssl s_client -showcerts -connect host:port
Try generating a new ssl cert in the logsatsh server (10.90.9.242) with the IP-SAN alternate name which means editing the /etc/ssl/openssl.cnf and adding:
subjectAltName = IP:10.90.9.242
under the [v3_ca] section.
and only afterwards generating the cert and key by running:
openssl req -x509 -batch -nodes -newkey rsa:2048 -keyout /etc/pki/tls/private/logstash-forwarder.key -out /etc/pki/tls/certs/logstash-forwarder.crt -days 3650
Don't forget to reset the logstash and move the crt and key to the correct path of the logstash-forwarder (written in the config file).

Resources