grpc: [Node.js] Handshake failed with fatal error SSL_ERROR_SSL: BAD_ECC_CERT

Hello, I am trying to connect from node.js script to external grpc API using TLS with self signed cert (please see below) but during the handshake grpc terminates with following error:

E0527 09:49:28.689000000  4712 ssl_transport_security.c:945] Handshake failed with fatal error SSL_ERROR_SSL: error:1000006b:SSL routines:OPENSSL_internal:BA
D_ECC_CERT.
E0527 09:49:28.689000000  4712 handshake.c:241] Handshake failed with error TSI_PROTOCOL_FAILURE
E0527 09:49:28.689000000  4712 secure_channel_create.c:99] Secure handshake failed with error 1.
{ [Error] code: 14, metadata: Metadata { _internal_repr: {} } }

I am running Node.js (v.4.4.5 LTS) under win 7 (x64bit) with GRPC package (v. 0.14.1) installed via npm install grpc --save.

The script I am running is this:

var fs = require('fs');
var path = require('path');
var os = require('os');

process.env['GRPC_SSL_CIPHER_SUITES'] = 'HIGH+ECDSA';

var grpc = require('grpc');
var protoDescriptor = grpc.load('./api.proto');
var walletrpc = protoDescriptor.walletrpc;

var cert = fs.readFileSync('rpc.cert');
var creds = grpc.credentials.createSsl(cert);
var client = new walletrpc.WalletService('127.0.0.1:9110', creds);

var request = {
    account_number: 0,
    required_confirmations: 1
};
client.balance(request, function(err, response) {
    if (err) {
        console.error(err);
    } else {
        console.log('Spendable balance:', response.spendable);
    }
})

Certificate file is standard certificate:

Please help me with this error - where is the problem/how should I debug it ? Is it cert problem - GRPC problem ? Thank you very much in advance for any help!

About this issue

Original URL
State: open
Created 8 years ago
Comments: 33 (10 by maintainers)

Most upvoted comments

For the sake of documentation, the offending code is:

https://github.com/grpc/grpc/blob/7b63731b87ccdcc24b03e25f13a2bb91d0531b0f/src/core/tsi/ssl_transport_security.cc#L695

It appears this code was added to configure ECDH to use P-256, but it has the side effect of also restricting ECC certificate keys to that curve.

ssiloti on Feb 28, 2019

Certs using the P-256 curve are working fine.

jrick on Aug 4, 2017

I notice that the certificate you are using uses IP addresses as Subject Alternative Names. And the primary difference between the Linux and Windows versions of the gRPC library is that the Linux library uses OpenSSL and the Windows library uses BoringSSL. It may be that BoringSSL cannot handle that kind of certificate.

As an alternative to using machine-specific certificates for testing, you can use a regular certificate for a domain, and initialize the client with a couple of extra options. For example, you could use a self-signed certificate for example.com and change the client construction line to this:

var options = {
  'grpc.ssl_target_name_override' : 'example.com',
  'grpc.default_authority': 'example.com'
};
var client = new walletrpc.WalletService('127.0.0.1:9110', creds, options)

This will make the client validate the certificate it receives as though it came from example.com.

murgatroid99 on May 27, 2016

To add more detail to this issue, the same client and server code work fine on Linux, but the client is unable to connect when running on Windows.

Keys and certificates are being generated with this code: https://github.com/decred/dcrutil/blob/85fac3a15425f15408f1dcec28bfd4b18ea2f882/certgen.go#L25

There is also a standalone tool that can be used to generate the keypairs (can be useful for reproducing this issue with other servers). To install: go get -u github.com/decred/dcrd/cmd/gencerts.

jrick on May 27, 2016

This also happens on the Python library.

In any case, P384 curves are not supported. You have to use P256. Probably a BoringSSL issue.

lawliet89 on Feb 26, 2019