Skip to content

Opencode (Windows) ignores NODE_EXTRA_CA_CERTS environment variable #17798

New issue
New issue
Closed as not planned
Closed as not planned
Opencode (Windows) ignores NODE_EXTRA_CA_CERTS environment variable#17798
Assignees
Hona

Description

@watashi93
watashi93
opened on Mar 16, 2026

Description

In our company, we are using an proxy which "opens" TLS enrcyption with outside of our network for DPI. This proxy issues certificates using an internal PKI. Our internal LLM models also use certificates from our internal PKI. I am running opencode in the version 1.2.24 using Node 24.14.0 on Windows 11. I have set the environment variable NODE_EXTRA_CA_CERTS pointing to a file which contains the root certificate of our internal PKI in PEM format. The certificate is valid (today is between notBefore/notAfter).

The problem:
whenever I try to use any model (internal and external) I get the error message "certificate has expired" (which definitely is wrong, any error message regarding a self-signed certificate would be correct - assuming the environment variable is ignored or our root certificate has a problem).

Steps to identify the problem:

  1. Exception of external URLs of some models from SSL Decryption: these URLs work, the internal URL does not work
  2. Set NODE_TLS_REJECT_UNAUTHORIZED to 0: everything works as expected - apart from having a security issue
  3. Run simple programs in Node which only access these URLs: NODE_EXTRA_CA_CERTS is used, and everything works. Without NODE_EXTRA_CA_CERTS, I get the expected error message about self-signed certificates
  4. Run opencode in a container on the windows machine - everything works as expected.
  5. Tried the same setup in Node-Versions 20, 21 and 25

This points to a problem of the opencode-code in combination with Node for Windows. According to Copilot, Node for Windows seems to be a bit sensitive and ignores at least TLS-related environment variables, if:

  • if the app overwrites https.globalAgent.options.ca
  • if a package like axios, request, node-fetch, got replaces agents internally
  • if the application is using tls.createSecureContext() directly

I did look at the other cases, the search has returned, but setting NODE_TLS_REJECT_UNAUTHORIZED to 0 is not a solution. Excluding URLs from SSL decryption is a workaround, but not a solution. The same is true for replacing the internal certificates for our internal models with certificates from public CAs.

Plugins

No response

OpenCode version

1.2.24

Steps to reproduce

  1. open Powershell (or command)
  2. set the environment variable NODE_EXTRA_CA_CERTS to the complete path of the internal root certificate
  3. start opencode
  4. select any model
  5. enter "hi" or anything

Screenshot and/or share link

No response

Operating System

Windows 11

Terminal

Windows Terminal

Activity

  1. watashi93
    added
    bugSomething isn't working
    on Mar 16, 2026
  2. github-actions
    assigned
    rekram1-node
    on Mar 16, 2026
  3. github-actions
    added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    windows
    on Mar 16, 2026

  4. github-actions commented on Mar 16, 2026

    @github-actions
    github-actionsBot
    on Mar 16, 2026 – with GitHub Actions
    Contributor

    This issue might be related to an existing issue. Please check:

    • SSL_CERT_FILE env not observed since v0.15.0 #3130: Same corporate DPI proxy scenario where SSL certificate environment variables are not observed by opencode, with the same NODE_TLS_REJECT_UNAUTHORIZED=0 workaround — though that issue is specifically about SSL_CERT_FILE rather than NODE_EXTRA_CA_CERTS.

  5. watashi93 commented on Mar 16, 2026

    @watashi93
    watashi93
    on Mar 16, 2026
    Author

    The case #3130 is very similar indeed. The big difference is, that our problem seems to be Windows-related. We don't have any problems on Linux. Unfortunately, Windows is our desktop OS.

    BTW, the solution the user okimanedeep mentioned definitively does not work for us.

  6. rekram1-node
    assigned
    Hona
    and unassigned
    rekram1-node
    on Mar 16, 2026
  7. thdxr
    removed
    bugSomething isn't working
    windows
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on May 3, 2026

  8. cargocultprogramming commented on Jun 9, 2026

    @cargocultprogramming
    cargocultprogramming
    on Jun 9, 2026

    I can confirm a similar issue on wsl (in win11). I've set up the (company-self-signed) certs in wsl manually and they work just fine. However opencode does not pick them up (returns with error: Self signed certificate in certificate chain) and setting NODE_EXTRA_CA_CERTS, NODE_USE_SYSTEM_CA or trying to pass these as NODE_OPTIONS doesn't help unfortunately.

    The only way I can work around this problem is to set NODE_TLS_REJECT_UNAUTHORIZED=0 which is not ideal.

    I have no issues whatsoever with other certificates (non-self-signed), when connecting to external providers. However this prevents me from connecting securely to a local endpoint that I'd like to use.

  9. KSCGM commented on Aug 5, 2026

    @KSCGM
    KSCGM
    on Aug 5, 2026

    Update: The issue described below is solved, a second certificate was missing.

    I can confirm a similar issue on wsl (in win11). I've set up the (company-self-signed) certs in wsl manually and they work just fine. However opencode does not pick them up (returns with error: Self signed certificate in certificate chain) and setting NODE_EXTRA_CA_CERTS, NODE_USE_SYSTEM_CA or trying to pass these as NODE_OPTIONS doesn't help unfortunately.

    The only way I can work around this problem is to set NODE_TLS_REJECT_UNAUTHORIZED=0 which is not ideal.

    I have the same setup on my company machine: WSL in Windows 11 with self signed certificate, that works fine otherwise.
    Also I have the exact same error: "self signed certificate in certificate chain"
    The only way I found to make it work is also to set NODE_TLS_REJECT_UNAUTHORIZED=0, which is not a solution I can use.
    All other env vars I have tried (NODE_EXTRA_CA_CERTS, SSL_CERT_FILE, SSL_CERT_DIR, BUN_OPTIONS="--use-system-ca", NODE_OPTIONS="--use-system-ca") did not work, no matter if I set them in the terminal, via .bashrc or /etc/environment.

    From log:

    error="self signed certificate in certificate chain" stack="Error: self signed certificate in certificate chain\n    at async <anonymous> (/$bunfs/root/chunk-sfa3kdpq.js:439:92802)\n    at async <anonymous> (/$bunfs/root/chunk-22ym6391.js:6:12661)\n    at async doStream (/$bunfs/root/chunk-1540qec5.js:2:9456)\n    at async <anonymous> (/$bunfs/root/chunk-qwf8w8vx.js:15:33522)\n    at async <anonymous> (/$bunfs/root/chunk-qwf8w8vx.js:10:1587)\n    at async BZ (/$bunfs/root/chunk-qwf8w8vx.js:10:5919)\n    at async F (/$bunfs/root/chunk-qwf8w8vx.js:15:32668)\n    at async <anonymous> (/$bunfs/root/chunk-qwf8w8vx.js:15:38982)\n    at async <anonymous> (/$bunfs/root/chunk-qwf8w8vx.js:10:1587)"

  10. t-huebner-id commented on Aug 6, 2026

    @t-huebner-id
    t-huebner-id
    on Aug 6, 2026

    I was able to fix this locally following the workaround reported in anthropics/claude-code#71554.

    If you're encountering this on Windows:

    • Open certlm.msc (Win + R).
    • Go to Trusted Root Certification Authorities -> Certificates.
    • Locate and delete any expired corporate CA certificates

    Once removed, it worked immediately without restarting.

  11. nodje commented on Sep 7, 2026

    @nodje
    nodje
    on Sep 7, 2026

    I have the same issue on Linux TUI 1.18.18

  12. kat-japan commented on Sep 8, 2026

    @kat-japan
    kat-japan
    on Sep 8, 2026

    Notice: This document was created by Claude Opus.

    We hit this exact symptom on Windows in an opencode-based desktop app (OpenWork), and found a cause that would explain getting "certificate has expired" for a certificate that is perfectly valid. Posting it here in case it saves someone else the day it cost us.

    (The code snippets below are from that app's Electron main process rather than opencode itself, but the failure mode applies to any design that injects the Windows certificate stores as trust anchors, so it may well be the same thing you are seeing.)

    What was actually wrong

    The app collects certificates from the Windows stores and installs them as trust anchors:

    const defaultCerts = tls.getCACertificates("default");
tls.setDefaultCACertificates(dedupeCertificates([...defaultCerts, ...certificatesFromWindowsStores]));

    and the Windows collection step enumerates four stores:

    $stores = @('Cert:\LocalMachine\Root', 'Cert:\LocalMachine\CA', 'Cert:\CurrentUser\Root', 'Cert:\CurrentUser\CA')

    Two things go wrong there:

    1. Cert:\*\CA is not a trust store. On Windows that is Intermediate Certification Authorities, a cache that Windows fills automatically from AIA fetches while you browse. Nobody ever decided to trust its contents as anchors. Node's own --use-system-ca deliberately does not read it on Windows (--use-system-ca support for intermediate certificates on Windows nodejs/node#57163).
    2. Expired certificates are never filtered out. On our machine the resulting bundle contained 16 expired certificates.

    The combination is fatal. Our CurrentUser\CA happened to hold an old cross-signed CN=ISRG Root X2 (issuer ISRG Root X1, expired 2025-09-16). Node's default list contains the valid self-signed CN=ISRG Root X2 (good until 2040). Same Subject, both installed as anchors, so OpenSSL builds the path into the expired one and stops. Same shape as the DST Root CA X3 breakage in 2021.

    That explains the confusing parts of this issue:

    • the error says "expired" even though your own CA is perfectly valid -- the expired certificate is an unrelated one that got added to the anchor set
    • plain node works, because it never loads that cache
    • NODE_EXTRA_CA_CERTS looks "ignored" -- nothing is missing from the trust set, something poisonous was added to it, so adding one more certificate cannot help
    • NODE_TLS_REJECT_UNAUTHORIZED=0 "fixes" it, because it stops path building from mattering at all

    How we confirmed it

    We rebuilt the trust set four different ways inside the app's own Node runtime and fetched the same HTTPS endpoint each time:

    trust set result
    Node defaults only connects
    defaults + Windows stores (what the app does) CERT_HAS_EXPIRED
    same, minus only the one expired ISRG Root X2 connects
    same, minus all 16 expired certificates connects

    Workaround, if anyone else is stuck

    List expired certificates sitting in the intermediate cache:

    Get-ChildItem Cert:\CurrentUser\CA, Cert:\LocalMachine\CA |
  Where-Object { $_.NotAfter -lt (Get-Date) } |
  Format-Table Subject, NotAfter, Thumbprint

    Back one up and remove it, then restart the app so its CA bundle is regenerated:

    certutil -user -store    CA <thumbprint> backup.cer
certutil -user -delstore CA <thumbprint>
:: to restore it later
certutil -user -addstore CA backup.cer

    Removing that single certificate fixed everything for us.

    What we would like to see, longer term

    Ideally the Windows path would get the same treatment the macOS path already has. The macOS code restricts itself to admin-controlled keychains, with this reasoning in a comment:

    // Admin-controlled keychains only. `find-certificate` ignores trust settings, so
// including the user-writable login keychain would let any local process widen
// what the desktop trusts; user-domain roots go through NODE_EXTRA_CA_CERTS.

    That is exactly the right instinct, and it is missing on Windows: Cert:\CurrentUser\CA is user-writable, needs no elevation, and grows on its own as you browse. Concretely, mirroring the macOS approach would mean:

    1. read only Root and AuthRoot, not CA (if intermediates are wanted for chain completion, keep them in a separate list and never install them as anchors)
    2. drop any certificate whose notAfter is already in the past before injecting it
    3. log how many anchors were added and what was dropped, so this fails loudly rather than silently

    Sharing this in good faith because the symptom is genuinely hard to track down -- there is no need to reply on my account, and please feel free to close this or move it wherever it belongs.

  13. thdxr commented on Oct 11, 2026

    @thdxr
    thdxr
    on Oct 11, 2026
    Member

    Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

    — from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

  14. thdxr
    closed this as not plannedon Oct 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions