TLS fails reading self-signed certificate on node 4.2.5+

[dbkup]

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.

[diegossilveira]

@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.

[dbkup]

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

[MylesBorins]

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

[MylesBorins]

/cc @jasnell

[indutny]

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

[indutny]

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

[indutny]

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

[indutny]

Should be fixed by #5109

[jasnell]

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).

[indutny]

@jasnell do you think we should break this behavior in next major release? I mean should we make pfx non-ca?

[dbkup]

@indutny Nice reaction time, thank you :). I've since checked my certs once more. I have a local CA which was used for signing the client/server certificates in question. Seems to me that this behaviour should be supported for use in an internal network, i.e. the certs are used in a controlled environment.

I have also tried generating another set of certs using openssl 1.0.1f, suspecting a compatibility issue of some sorts, getting other errors, like UNABLE_TO_VERIFY_LEAF_SIGNATURE and DEPTH_ZERO_SELF_SIGNED_CERT (on v4.2.4) so I guess I'm not doing something right. I will check your update for my case when it's available.