Unable to access api.pulsar-edit.dev on corporate network: "self signed certificate in certificate chain"

[wesinator]

Thanks in advance for your bug report!

• Have you reproduced issue in safe mode?
• Have you used the debugging guide to try to resolve the issue?
• Have you checked our FAQs to make sure your question isn't answered there?
• Have you checked to make sure your issue does not already exist?
• Have you checked you are on the latest release of Pulsar?

What happened?

If the device is connected to a corporate network that uses an org signed intermediate certificate for all network traffic, the client gives fetch errors on https://api.pulsar-edit.dev which prevents any packages from being installable in this scenario.

Pulsar version

v1.121.0

Which OS does this happen on?

🍎 macOS

OS details

14.7

Which CPU architecture are you running this on?

Apple M-series

What steps are needed to reproduce this?

1. system network config that uses a intermediate TLS certificate, like enterprise orgs or certain wifi networks.
2. Settings - Packages - search for a package to install, or click install on a recommended package.

$ cat /Users/user/.pulsar/.apm/_logs/2024-10-18T00_00_00_004Z-debug.log

0 info it worked if it ends with ok

1 verbose cli [

1 verbose cli   '/Applications/Pulsar.app/Contents/Resources/app/ppm/bin/node',

1 verbose cli   '/Applications/Pulsar.app/Contents/Resources/app/ppm/node_modules/npm/bin/npm-cli.js',

1 verbose cli   '--globalconfig',

1 verbose cli   '/Users/user/.pulsar/.apm/.apmrc',

1 verbose cli   '--userconfig',

1 verbose cli   '/Users/user/.pulsar/.apmrc',

1 verbose cli   'install',

1 verbose cli   'https://api.pulsar-edit.dev/api/packages/atom-clock/versions/0.1.18/tarball',

1 verbose cli   '--target=12.2.3',

1 verbose cli   '--disturl=https://artifacts.electronjs.org/headers/dist',

1 verbose cli   '--arch=arm64',

1 verbose cli   '--force-process-config',

1 verbose cli   '--global-style'

1 verbose cli ]

2 info using [email protected]

3 info using [email protected]

4 verbose npm-session b7d622faf239339b

5 silly install loadCurrentTree

6 silly install readLocalPackageData

7 silly fetchPackageMetaData error for https://api.pulsar-edit.dev/api/packages/atom-clock/versions/0.1.18/tarball request to https://api.pulsar-edit.dev/api/packages/atom-clock/versions/0.1.18/tarball failed, reason: self signed certificate in certificate chain

8 timing stage:rollbackFailedOptional Completed in 0ms

9 timing stage:runTopLevelLifecycles Completed in 108ms

10 verbose type system

11 verbose stack FetchError: request to https://api.pulsar-edit.dev/api/packages/atom-clock/versions/0.1.18/tarball failed, reason: self signed certificate in certificate chain

11 verbose stack     at ClientRequest.<anonymous> (/Applications/Pulsar.app/Contents/Resources/app/ppm/node_modules/npm/node_modules/node-fetch-npm/src/index.js:68:14)

11 verbose stack     at ClientRequest.emit (node:events:365:28)

11 verbose stack     at TLSSocket.socketErrorListener (node:_http_client:447:9)

11 verbose stack     at TLSSocket.emit (node:events:365:28)

11 verbose stack     at emitErrorNT (node:internal/streams/destroy:193:8)

11 verbose stack     at emitErrorCloseNT (node:internal/streams/destroy:158:3)

11 verbose stack     at processTicksAndRejections (node:internal/process/task_queues:83:21)

12 verbose cwd /private/var/folders/cn/5cbchh117_913978zdc_64snkmnjdk/T/apm-install-dir-2024918-82055-1d4iizg.8vvm

13 verbose Darwin 23.6.0

14 verbose argv "/Applications/Pulsar.app/Contents/Resources/app/ppm/bin/node" "/Applications/Pulsar.app/Contents/Resources/app/ppm/node_modules/npm/bin/npm-cli.js" "--globalconfig" "/Users/user/.pulsar/.apm/.apmrc" "--userconfig" "/Users/user/.pulsar/.apmrc" "install" "https://api.pulsar-edit.dev/api/packages/atom-clock/versions/0.1.18/tarball" "--target=12.2.3" "--disturl=https://artifacts.electronjs.org/headers/dist" "--arch=arm64" "--force-process-config" "--global-style"

15 verbose node v16.0.0

16 verbose npm  v6.14.19-pulsar1-1

17 error code SELF_SIGNED_CERT_IN_CHAIN

18 error errno SELF_SIGNED_CERT_IN_CHAIN

19 error request to https://api.pulsar-edit.dev/api/packages/atom-clock/versions/0.1.18/tarball failed, reason: self signed certificate in certificate chain

20 verbose exit [ 1, true ]

Additional Information:

several issues were reported in Atom
atom/atom#16964
atom/atom#8465

I tried atom/apm#340 (comment) $ NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt pulsar after copying the top-level org CA cert, and this didn't work.

there is this package designed for "adding extra certificates to Atom's trust store" https://github.com/nikitakit/cert-tweaks . I don't know if this still works in the latest version of Pulsar

I realise this may be considerd an edge case requiring customisation and not a bug in pulsar itself.

[savetheclocktower]

The good news is that any package can be installed directly from GitHub — just use owner/repo-name syntax:

ppm install b3by/atom-clock

This should do the right thing in most circumstances, and will even detect when updates are available if new commits are pushed to master or main. Not ideal, but at least a workaround for now.

[wesinator]

@savetheclocktower I ran that command and it had the same error although it the output suggests that the git clone worked correctly.

$ ppm install b3by/atom-clock

Cloning https://github.com/b3by/atom-clock.git ✓
Installing modules ✗
npm ERR! code SELF_SIGNED_CERT_IN_CHAIN
npm ERR! errno SELF_SIGNED_CERT_IN_CHAIN
npm ERR! request to https://registry.npmjs.org/moment failed, reason: self signed certificate in certificate chain

npm ERR! A complete log of this run can be found in:

I also tried using a different intermediate CA (not the root CA) as the node export variable.

[savetheclocktower]

If it can't even talk to NPM, then that's ridiculous, and I don't know how you get any work done.

I understand how Pulsar's own server may not exactly be on a large company's radar, but NPM is pretty critical infrastructure for any programmer. It's a subsidiary of GitHub.

I'm not sure I even understand the error being described here. A “self-signed” certificate, by my understanding, is something that you can make that carries no implicit authority or proof that you are who you say you are; it's something you'd do if you just wanted to use HTTPS locally without jumping through hoops. I am extremely skeptical that it's something that would apply to NPM in the year 2024.

Anyway, you can try this if you have npm installed locally (though it wouldn't surprise me if you didn't):

• cd ~/.pulsar/packages/atom-clock
• npm install

If you get the same error with a recent version of npm, I'd be pretty gobsmacked.

I found this page. I doubt the exact cause is the same, but the possible solutions may work — though you'd want to substitute ppm for npm if you run any commands here. Some of them, like disabling strict SSL, are probably bad ideas, but you might judge them to be acceptable as temporary measures.

If none of that works, my suggestion would be to reach out to your company's IT department and explain the situation.

[confused-Techie]

@savetheclocktower From my understanding of the issue at hand:
The company's firewall provides users with it's own self-signed certificate, which allows them to have the encryption keys for all traffic on the network. It's used so that the firewall can do SSL decryption on the fly and inspect traffic at all times for security.

Generally the managed devices would be configured to accept the firewall's certificate as valid, but from what my research is showing is that superagent (the HTTP library used within PPM) doesn't accept the custom trusted certificates on the host machine, and instead essentially brings it's own.

Unfortunately, we can't add a quick fix to disable TLS for a specific request since the library's author seems quite against the idea. Which does mean hacks like process.env['NODE_TLS_REJECT_UNAUTHORIZED'] = 0; or npm config set strict-ssl false while they should work, also would mean all secure communication within Node or NPM is now insecure, which seems like a very bad idea.

But considering traffic to NPM seems to be getting blocked, I'd absolutely reach out to IT like previously suggested.

---

EDIT:

It seems we may have some options within superagent to customize the certificates we trust. Frustrating that it doesn't automatically trust what the OS has, but we could use the node configuration values to automatically update it, or allow these to be customized otherwise. But still if NPM is being blocked, this wouldn't help in this particular case.

[savetheclocktower]

That at least suggests that the user's own copy of npm might fare better, and would get them past the npm install step.

[confused-Techie]

So diving deeper into this, it's an issue within NodeJS itself.

Since superagent and most sane HTTP request libraries at the end of the day all use Node's own http/https/http/2 libraries to interact with the outside world.

It turns out that TLS is implemented in all of these via the NodeJS tls module, which has a list of hardcoded root certificates.

An immutable array of strings representing the root certificates (in PEM format) from the bundled Mozilla CA store as supplied by the current Node.js version.
The bundled CA store, as supplied by Node.js, is a snapshot of Mozilla CA store that is fixed at release time. It is identical on all supported platforms.

Seems NodeJS pays the operating system itself zero respect for what it trusts and instead relies totally on Mozilla.

So we have two options:

1. Attempt to auto detect where additional certs would be stored per OS, and load those as well.
2. Give the user a configurable setting that allows adding new certs.

I'm obviously much more a fan of number 2, since it's less work on our end, and means we don't have to study and update where-ever certs are stored on each OS. Now it does seem the easiest way to utilize custom certs would still be within superagents options itself, but would be nice to see if there's anyway to add them process wide for NodeJS, so it works for every part of Pulsar, and maybe could help prevent us having to update it as often in the future

[wesinator]

@confused-Techie I think https://github.com/nikitakit/cert-tweaks exists to do #2.