Updater Service - SSL Certificate Unrecognized

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I’m running Cursor on macOS behind a corporate TLS-inspecting proxy that re-signs HTTPS with a custom root CA. Cursor’s updater service reports the proxy-signed certificate as unrecognized in the diagnostics output, even though the CA is trusted system-wide and every other tool on the machine (including curl) recognizes and accepts the cert without extra configuration. The rest of Cursor works normally — this is scoped to the updater.

To be clear: this is not a TLS handshake failure. The cert is valid and signed by a CA that’s explicitly trusted in the macOS System keychain. The updater simply doesn’t recognize the cert as one it trusts and flags it in diagnostics.

What I’ve already done:

  1. Installed the custom root CA in my macOS System keychain and explicitly marked it “Always Trust.” curl and every other tool on the
    machine recognize the cert without extra flags.
  2. Launched Cursor from the terminal with every env var I could find documented:
    NODE_REJECT_UNAUTHORIZED=0 \
    NODE_EXTRA_CA_CERTS=/path/to/root-ca.pem
    cursor
  3. Tried these individually and in combination. Diagnostics still flag the cert as unrecognized.
  4. Already have these in Cursor settings:
    “http.experimental.systemCertificatesV2”: true,
    “cursor.general.disableHttp2”: true,
    “cursor.general.disableHttp1SSE”: true

Expected behavior:

The updater should recognize certificates signed by CAs in the system keychain, just like the rest of macOS does by default and like other Cursor subsystems appear to. Failing that, NODE_EXTRA_CA_CERTS should provide a supported escape hatch. http.experimental.systemCertificatesV2: true strongly implies the OS trust store is supposed to be consulted.

Actual behavior:

Diagnostics report the proxy-signed cert as unrecognized by the updater. Behavior is identical with or without any of the env vars above. The rest of Cursor (chat, Tab, etc.) works fine against the same proxy, which suggests the updater uses a separate code path that isn’t consulting the same trust sources.

What I suspect is going on:

  • http.experimental.systemCertificatesV2 appears to cover some Cursor subsystems but not the updater.
  • The updater likely makes its HTTPS call through a code path that doesn’t consult NODE_EXTRA_CA_CERTS or the system keychain, so any CA
    the proxy re-signs with is unknown to that path regardless of how it’s installed.
  • cursor.general.disableHttp2 / disableHttp1SSE exist because Cursor has clearly hit MITM-proxy issues before, but they don’t change this
    behavior.

Ask:

  1. Is there a supported way to get the updater to recognize a custom root CA on macOS, short of NODE_REJECT_UNAUTHORIZED=0?
  2. If not, can we get a first-class setting for this — e.g. cursor.tls.customCACerts: [“/path/to/ca.pem”], or a ~/.cursor/ca-certs/
    directory that Cursor loads on startup? Working from behind a TLS-inspecting proxy is table stakes for most enterprise environments.
  3. Is systemCertificatesV2 expected to cover the updater path, or is that a known gap?

Steps to Reproduce

  1. Set up a TLS-inspecting HTTPS proxy that re-signs traffic with a custom root CA (e.g. mitmproxy, Zscaler, or any corporate
    SSL-inspection gateway).
  2. On a clean macOS machine, route traffic through that proxy.
  3. Export the proxy’s root CA as a .pem file.
  4. Import the CA into the macOS System keychain via Keychain Access and set it to “Always Trust.”
  5. Verify trust outside Cursor: curl -v https:// succeeds with no extra flags and shows the proxy-signed cert chain.
  6. Open Cursor and add the following to settings.json:
    “http.experimental.systemCertificatesV2”: true,
    “cursor.general.disableHttp2”: true,
    “cursor.general.disableHttp1SSE”: true
  7. Fully quit Cursor (Cmd+Q, not just close the window).
  8. Relaunch Cursor from a terminal with:
    NODE_REJECT_UNAUTHORIZED=0
    NODE_EXTRA_CA_CERTS=/path/to/root-ca.pem \
    cursor
  9. Let the updater run (or trigger a check for updates from the menu) and open Cursor’s diagnostics.
  10. Observe: diagnostics flag the proxy-signed certificate as unrecognized by the updater, even though curl to the same endpoint from the same shell accepts it and the rest of Cursor works normally.

Expected Behavior

Expected: Updater recognizes the cert, since the CA is trusted system-wide and NODE_EXTRA_CA_CERTS is set.
Actual: Diagnostics list the updater’s cert as unrecognized.

Operating System

MacOS

Version Information

Version: 3.1.17 (Universal)
VSCode Version: 1.105.1
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Date: 2026-04-19T19:33:58.189Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.2.0

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report. I’ll break down what’s going on since it’s easy to mix up a few layers here.

About the warning in Diagnostics. The TLS check in Diagnostics intentionally marks certs signed by non-public CAs as unrecognized. That’s a way to detect MITM or inspection proxies. With a TLS-inspecting gateway, the issuer will always be your proxy’s CA, so the warning will trigger no matter whether the system trusts that CA. This is an informational warning, not a sign that something is functionally broken.

About the updater on macOS. It uses Electron’s native networking stack, not Node https. So:

  • NODE_EXTRA_CA_CERTS and NODE_REJECT_UNAUTHORIZED don’t affect the updater. They are Node-only.
  • http.experimental.systemCertificatesV2 doesn’t cover all Cursor paths. The main process updater is not in its scope.
  • cursor.general.disableHttp2 / disableHttp1SSE are for AI transport and are not related to the update path.

Main question: are updates actually not installing for you? Does Check for Updates fail and the new version doesn’t download. Or is it only the Diagnostics warning, and updates work fine in practice. The native stack usually respects the System keychain with Always Trust, so if the CA is trusted system-wide, it should work. If the updater itself is failing, please share what the updater logs say, not Diagnostics. That’ll help separate these two cases.

About the feature request for something like cursor.tls.customCACerts or ~/.cursor/ca-certs/. That’s a reasonable ask, it’s a basic enterprise need. Related thread: Trusting System Certificates or Adding Custom CAs, please subscribe there.

6

Thank you for the quick response.

I now understand that the diagnostics are intended to simply reveal to the user that the CA is not public. That also aligns with my usage of the application, chats, tab completion, agents are working as expected.

However, the Update Service seems to alert the user that the certificate is invalid, yet prompts the user to connect to the server anyway, but there is no available action for the user to continue updating. We’re instructing users to redownload from the website and replace their application, which is not ideal because there may be settings that get reverted to defaults.

If the updater was on a separate domain, we could allow list that domain and not perform TLS inspection at our org. Otherwise, if it will continue to live at api2.cursor.sh along with AI inference traffic, we’ll need a way for the Update Service to trust our CA.

EDIT: Another user is reporting the Update Service error as The operation couldn’t be completed. (NSURLErrorDomain error -1012.). Perhaps this reveals something new?

Thanks again!

image
image343×147 6.59 KB