Error: connect EPERM when connecting to https server with self signed certificate

[bamanuel]

• Version: v8.10.0
• Platform: Windows 10 x64 (behind proxy)
• Subsystem:

When connecting to https url with self signed certificate, the following error is thrown:

Error: connect EPERM /
at Object._errnoException (util.js:1019:11)
at _exceptionWithHostPort (util.js:1041:20)
at PipeConnectWrap.afterConnect [as oncomplete] (net.js:1175:14)

The issue isn't system independent and happens starting with nodev8.6.0. The code below works fine on nodev8.5.0 or lower on same machine

const https = require("https");
const fs = require("fs");
var globalAgent = https.globalAgent;
globalAgent.options = {ca: [fs.readFileSync('./caTrust.cer')]};// caTrust.cer contains self signed certificate for target url

const url = 'https://target.localhost'
https.get(url, response => {
    console.log(response);
});

When using request library to make the https call, it throws a slightly different error: Error: connect ENOENT

[apapirovski]

I think this might be a duplicate of #16196?

[bamanuel]

It's very likely a duplicate of that issue, although I'm not 100% certain. The target server I was testing with only supports the following ciphers:

• AES256-SHA
• AES128-SHA
• RC4-SHA
• RC4-MD5
• DES-CBC3-SHA

[bnoordhuis]

Can you connect with openssl s_client? What does it print?

[bamanuel]

Output from openssl s_client (without the cert):

No client certificate CA names sent
---
SSL handshake has read 1197 bytes and written 650 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES256-SHA
    Session-ID: CD6C6B370C265ADA2D4D6A712693AEC74841118CAA8F090CAC1CD754B0EAFFC2
    Session-ID-ctx:
    Master-Key: 0B9A0F402337BFB84891CC7682E36DFF243A5B19C3065F7909988E512B2D648760259D9DEF18DD468255D9A15CF5C7BA
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 600 (seconds)
    TLS session ticket:
    0000 - 35 bd 18 d6 74 22 13 a0-3d 66 03 41 a1 0b 62 61   5...t"..=f.A..ba
    0010 - e0 f4 0e c1 37 d8 f6 6c-bb e8 2c 69 f9 3c 00 13   ....7..l..,i.<..
    0020 - 2d 9a a8 d7 74 c7 fa aa-bc 61 2c 62 51 14 de 25   -...t....a,bQ..%
    0030 - 45 d5 e3 b7 e3 fd 0c 2d-3e b9 19 31 b4 b0 25 b3   E......->..1..%.
    0040 - 99 8b 3e 48 5f a1 61 20-85 03 74 d6 ed 30 ce ba   ..>H_.a ..t..0..
    0050 - a4 f9 f1 d7 1d be 95 f9-60 aa 03 49 17 76 fe 57   ........`..I.v.W
    0060 - 2b d1 12 8e 11 65 a2 84-86 f6 7c d4 30 77 83 75   +....e....|.0w.u
    0070 - 64 55 e7 c4 bf df 80 10-d0 a5 46 b7 41 23 ff 5c   dU........F.A#.\
    0080 - a1 e2 02 b1 a6 9d ff fb-cc 08 31 bc 28 68 d4 f1   ..........1.(h..
    0090 - c1 b0 30 57 3a f5 12 dd-b8 65 5f ab d7 80 82 df   ..0W:....e_.....
    00a0 - 9b 65 97 94 77 55 84 3f-e2 b1 71 90 ee d4 7c 74   .e..wU.?..q...|t

    Start Time: 1523803449
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)

[bnoordhuis]

Okay, and what happens when you pass in the certificate with -CAfile?

[bamanuel]

New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES256-SHA
    Session-ID: AEDEA1E4249148FA09DDDF6ECC8F1C5DE92F0DC49E8C64E1EA7FB13E9AA7771A
    Session-ID-ctx:
    Master-Key: D279821B5338B02CECFB53B25C82C254FED4FB09EB9C15C5B981C0DC00615722051268F5B42EA1C2B76E18B94D292F5E
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 600 (seconds)
    TLS session ticket:
    0000 - 35 bd 18 d6 74 22 13 a0-3d 66 03 41 a1 0b 62 61   5...t"..=f.A..ba
    0010 - bb 74 a7 e3 ab d2 ac ef-e2 03 d4 18 fb 0b 38 51   .t............8Q
    0020 - 27 28 48 87 18 2f 9d 71-f3 89 23 ff d7 fd 0f 4d   '(H../.q..#....M
    0030 - e6 1e 33 d0 ea 21 a1 cb-ac b8 7d 02 cf 5a 6d 9c   ..3..!....}..Zm.
    0040 - 74 07 0b 83 96 a6 db 5b-f7 86 fe 3e 3c f1 23 36   t......[...><.#6
    0050 - 23 b1 48 a0 9b 0a aa 6d-b6 c4 61 e8 43 7e 76 74   #.H....m..a.C~vt
    0060 - 4f 90 3a 39 a7 3f 8c 30-dd 67 84 8e 06 10 8e c3   O.:9.?.0.g......
    0070 - 73 ec 59 6d cb b9 53 cc-f1 17 eb 50 ed c7 fd 40   s.Ym..S....P...@
    0080 - e0 c4 25 5c dc 34 b9 b5-3f 64 7b 5d f1 f2 00 56   ..%\.4..?d{]...V
    0090 - 8e d8 c2 a6 5a 06 b3 b2-24 30 ec 00 86 31 68 41   ....Z...$0...1hA
    00a0 - b7 a7 bb a0 6c df 08 b6-73 a3 89 56 84 40 ec c2   ....l...s..V.@..

    Start Time: 1523832718
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)

[bnoordhuis]

That's progress. :-). What happens when you do this?

const options = url.parse('https://target.localhost');
options.ecdhCurve = 'auto';
https.get(options, ...);

What when you add this?

options.ca = fs.readFileSync('./caTrust.cer');

[bamanuel]

Same issue for both cases Error: connect EPERM /

Both of them work when i remove the following lines. See initial ticket comment.

var globalAgent = https.globalAgent;
globalAgent.options = {ca: [fs.readFileSync('./caTrust.cer')]};

[bnoordhuis]

I don't see commits between v8.5.0 and v8.6.0 that are plausible candidates for such a regression. Are you sure v8.6.0 is the first release where this started happening for you?

[bamanuel]

Yes, issue started with v8.6.0. The exactly line causing the issue is:
globalAgent.options = {ca: [fs.readFileSync('./caTrust.cer')]};

Overwriting the entire globalAgent.options property (initially equals {path: null}) is causing the problem. Either of the following lines work:

globalAgent.options.ca = [fs.readFileSync('./caTrust.cer')];
\\ or
globalAgent.options = {path: null, ca: [fs.readFileSync('./caTrust.cer')]};

[richardlau]

Maybe due to #14564?

[bnoordhuis]

I saw that commit but I didn't see anything obviously wrong in the diff.

@bamanuel Have you checked what happens when you revert commit ee157e5? Worth a try.

[bamanuel]

It works after reverting ee157e5. I'm going to close this since options object shouldn't have been overwritten in the first place.

Thanks for help.

[bnoordhuis]

cc @bengl since I doubt that's the intended behavior.