TLS fails reading self-signed certificate on node 4.2.5+

I'm having an issue with ssl certificate validation using the tls module. The server is started with:

tls.createServer({
        pfx: fs.readFileSync(config.certFile),
        passphrase: config.keyPass,
        requestCert: true, 
        rejectUnauthorized: false 
    }, ...);

The client:

tls.connect({
    port: config.port,
    host:config.host,
    pfx: fs.readFileSync(config.cert),
    passphrase: config.pass,
    rejectUnauthorized: false
});

My issue is that I get tlsSocket.authorizationError SELF_SIGNED_CERT_IN_CHAIN on v4.2.5+ but not on older versions. Here's my output on a Windows machine, but the same happens on an Ubuntu server.

>nodist 4.2.5
>node --version
v4.2.5

>node server.js
server started:
auth->SELF_SIGNED_CERT_IN_CHAIN

>nodist 4.2.4
nodev4.2.4

>node server.js
server started:
auth->null

The auth-> line is printed to console with the tlsSocket.authorizationError parameter when a client connects. In the case of a successful connect this field is null.
Tested down to 0.12.9, all versions read the certificate without issues.

@dbkup

@dbkup, looks like this does not affect node from v5.0.0 to v5.3.0, right? I'm facing similar problem here with versions v5.4.0 and v5.5.0. Maybe, #4165, which was introduced in v5.4.0 and v4.2.5 is causing that.

@diegossilveira

@diegossilveira I tested with the v4 branch, so quite possible that that is the reason.

@indutny

there were three commits that landed on 4.2.5 that touched TLS. Perhaps @indutny has some insight

@jasnell

/cc @jasnell

It is definitely caused by that PFX commit. Reverting it fixes the issue. Will look more deeply into it.

This is where the issue comes from: a2c1799#diff-801e3948990f4965a8ea4aca4a423864L928 . Going to investigate the best way to fix it right now.

@dbkup

Ok, so I have several thoughts about this. There are two conflicting things in my opinion:

API stability
Sanity of the pfx option in tls.createServer/tls.connect

From stability point of view, we should not really break anything unless there is security need for this, and that commit is absolutely breaking change (as we have just figured out).

From sanity point of view, there is no way in PKCS12 (pfx) to distinguish between regular server/client certs and CA certs for validating the other side. It seems to be pretty unsafe to me, but this is the way it has been implemented and documented for a long time.

@dbkup is what pfx currently provides exactly what you need from it? Do you expect it to use the same certs for both client validation and sever authorization?

cc @nodejs/crypto @nodejs/ctc @nodejs/lts

Should be fixed by #5109

OK, let's get this fixed in the next LTS release after next week's security
release. Should be maybe a week later. I'm definitely thinking we need a RC
cycle tho for all LTS releases moving forward.
On Feb 5, 2016 2:34 PM, "Fedor Indutny" notifications@github.com wrote:

Should be fixed by #5109 #5109

—
Reply to this email directly or view it on GitHub
#5100 (comment).

test: disable gh-5100 test when in FIPS mode

crypto: add `pfx` certs as CA certs too

test: disable gh-5100 test when in FIPS mode

crypto: add `pfx` certs as CA certs too

test: disable gh-5100 test when in FIPS mode

crypto: add `pfx` certs as CA certs too

test: disable nodejsgh-5100 test when in FIPS mode

test: removed msg on assert.strictEqual on test-tls-pfx-nodejsgh-5100-…

test: rename regression tests file names

Navigation Menu

Repository navigation

TLS fails reading self-signed certificate on node 4.2.5+ #5100

12 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

TLS fails reading self-signed certificate on node 4.2.5+ #5100

Description

Activity

diegossilveira commented on Feb 5, 2016

dbkup commented on Feb 5, 2016

MylesBorins commented on Feb 5, 2016

MylesBorins commented on Feb 5, 2016

indutny commented on Feb 5, 2016

indutny commented on Feb 5, 2016

indutny commented on Feb 5, 2016

indutny commented on Feb 5, 2016

jasnell commented on Feb 5, 2016

12 remaining items

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions