Limitations of bun operation in corporate networks: self-signed CA

What version of Bun is running?

1.4.0

What platform is your computer?

Darwin 23.5.0 x86_64 i386
Darwin 24.2.0 arm64 arm

What steps can reproduce the bug?

environment: self-signed certificate in corporate network
trying to do any operation via bun runtime: "bunx bun-pr 16166", "bun install" or any other, which requires tls/https operations

What is the expected behavior?

No tls/https errors: the CA is invalid

What do you see instead?

HTTPThread: the CA is invalid

Additional information

Only exception is "bun install" command. For it, you can specify ca certificate for the install command via bunfig.toml. But that doesn't suit me (as a user who want adopt bun in SDLC) - I don't want to commit the certificate itself or the path to it. I don't want to be limited to the bun install command. I want to be able to set a single certificate for all operations performed through bun, like the NODE_EXTRA_CA_CERTS variable for a node. Or in other words, I want to configure my environment, via a variable once, and thus allow all bun commands to work correctly.

Right now this variable seems to work only for user code execution, but not for network operations of the bun commands themselves.

This issue:

Breaks rule "Bun aims for 100% Node.js compatibility."
Is a blocker for adoption bun in large companies with corporate networks

This issue happened on my mac.
bun add v1.2.19 (aad3abe)
🔍 Resolving [1/1] HTTPThread: the CA is invalid

Is there really 0 workarounds available for this?

🐛 fix(ci): pre-install dependencies in workflow to bypass SSL issues

I have run into a similar issue on a corporate machine. The error I receive is error: self signed certificate in certificate chain.

I have been debugging for the last couple of hours and have discovered that the following work:

Recommended approach

NODE_USE_SYSTEM_CA=1 bun index.ts

I am not sure if you need to add your corporate CA cert to your keychain. I did just in case, but when I removed it, everything still worked.

Disabling SSL. This is dangerous, but suggested in:
SELF_SIGNED_CERT_IN_CHAIN error when using proxyman #20001
Error whilst using @kubernetes/client-node: "Self signed certificate in certificate chain" #7332
error: SELF_SIGNED_CERT_IN_CHAIN downloading package manifest #7124
self signed certificate in certificate chain anomalyco/opencode#7073

NODE_TLS_REJECT_UNAUTHORIZED=0 bun index.ts

Important Note:
I have tried to specify the corporate CA cert .pem file with the environment variable NODE_EXTRA_CA_CERTS but that did not work on macOS with Bun v1.3.6

index.ts contents:

const response = await fetch("https://www.google.com");
const status = response.status;
console.log("Response status:", status);

@KirillTregubov

Setting NODE_USE_SYSTEM_CA=1 as an environment variable in Windows allowed me to get the UI to start properly as well.

Thanks @KirillTregubov!!

Fixed on main.

Verified on main at df84f8d (Linux): NODE_EXTRA_CA_CERTS is now honored by both user-code fetch() and Bun's own HTTP thread (bun install, bunx), not just user code.

# self-signed HTTPS server on localhost
$ NODE_EXTRA_CA_CERTS=/tmp/ca.pem bun -e 'await fetch(process.env.SERVER).then(r=>console.log(r.status))'
200
$ NODE_EXTRA_CA_CERTS=/tmp/ca.pem bun install   # registry = https://localhost:PORT
error: GET https://localhost:PORT/fakepkg - 404   # TLS handshake succeeded; no CA error

Without the env var both fail with DEPTH_ZERO_SELF_SIGNED_CERT. NODE_USE_SYSTEM_CA=1 / --use-system-ca is also available as an alternative for OS-keychain-installed corporate CAs.

@robobun

Fixed on main.

This issue still reproduces on Bun v1.4.0 (revision 34cbb9a):

buni *1 ❯  NODE_EXTRA_CA_CERTS=/etc/ssl/certs/internal-net.crt NODE_USE_SYSTEM_CA=1 bun install
bun install v1.4.0 (34cbb9a40)
HTTPThread: the CA is invalid
buni *1 ❯ echo $?
1
buni *1 ❯ NODE_EXTRA_CA_CERTS=/etc/ssl/certs/internal-net.crt yarn install --silent --pure-lockfile
(node:15252) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification.
(Use `node --trace-warnings ...` to show where the warning was created)
buni *1 ❯ echo $?                                                                                                                                                                                                                        31s
0

yarn install still works in this case.

@robobun can you reopen this issue ?

Workaround (tested for version 1.4.3):

NODE_TLS_REJECT_UNAUTHORIZED=0 bun install --cafile=<path-to-selfsigned-ca.file> # or install.cafile configured in bunfig.toml

Without NODE_TLS_REJECT_UNAUTHORIZED=0 you will get UNABLE_TO_GET_ISSUER_CERT_LOCALLY error.

Following approach:

NODE_TLS_REJECT_UNAUTHORIZED=0  NODE_EXTRA_CA_CERTS=<path-to-selfsigned-cert.crt> bun install

still not works (causing error HTTPThread: the CA is invalid )

Navigation Menu

Repository navigation

Limitations of bun operation in corporate networks: self-signed CA #17325

What version of Bun is running?

What platform is your computer?

What steps can reproduce the bug?

What is the expected behavior?

What do you see instead?

Additional information

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Limitations of bun operation in corporate networks: self-signed CA #17325

Description

What version of Bun is running?

What platform is your computer?

What steps can reproduce the bug?

What is the expected behavior?

What do you see instead?

Additional information

Activity

anru commented on Apr 23, 2025

ywj929 commented on Aug 5, 2025

Mattwmaster58 commented on Oct 6, 2025

KirillTregubov commented on Jan 16, 2026

rbanks54 commented on Jan 19, 2026

robobun commented on Jul 24, 2026

anru commented on Aug 21, 2026

anru commented on Oct 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions