Bug report: Cluster connection fails with "self signed certificate" on internal proxy (Windows, persists across reinstall/rollback)

Bug report: Cluster connection fails with "self signed certificate" on internal proxy (Windows, persists across reinstall/rollback)

Summary

On Windows, connecting to any Kubernetes cluster in Lens fails immediately with:

Internal Server Error (500): Failed to GET "https://127.0.0.1:<port>/<clusterId>/version"

The main-process log shows the actual cause:

error: [INTERNAL-PROXY-MAIN]: http proxy errored: Error: self signed certificate;
if the root CA is installed locally, try running Node.js with --use-system-ca
{ url: '/version', closed: false, clusterId: '<clusterId>' }
error: [CLUSTER-MANAGER-MAIN]: Failed to connect to clusterId="<clusterId>":
Error: Failed to GET "https://127.0.0.1:<port>/<clusterId>/version": Internal Server Error (500)

This happens for every cluster in the kubeconfig (tested with two independent clusters), and is fully reproducible across a clean reinstall and a version rollback (see below). kubectl against the exact same kubeconfig works with no issues, confirming the cluster API servers, network path, and credentials are all fine — the failure is isolated to Lens's internal kube-auth-proxy TLS handshake with itself.

Environment

• OS: Windows (client machine, domain-joined, corporate ESET Endpoint Security installed)
• Lens version at first report: 2026.6.260931-latest (Electron 42.4.0, Chrome 148.0.7778.254, Node 24.16.0)
• Update channel: Stable
• Kubeconfig: two contexts (mobi-dev, mobi-prod), both EKS-backed (*.eks.amazonaws.com)

What we ruled out (in order, with evidence)

1. Cluster/network health — Confirmed healthy via Grafana/Prometheus (up{job="apiserver"} = 1 for both API server instances, 0% 5xx rate on apiserver_request_total). Not a cluster-side issue.
2. kubectl works — kubectl get po and kubectl get nodes succeed against the same kubeconfig used by Lens.
3. Corporate TLS interception (ESET) — Directly inspected the certificate served by Lens's own proxy port using a raw SslStream connection from PowerShell:
   复制

   Subject : O=Lens, CN=Lens Certificate Authority
   Issuer  : O=Lens, CN=Lens Certificate Authority

   This confirms the certificate on the wire is Lens's own self-signed CA, not a corporate MITM-rewritten one. Also confirmed ESET's "Enable SSL/TLS" filtering toggle was off the whole time (policy-locked, viewable via Advanced Setup).
4. Environment variables — NODE_OPTIONS, NODE_EXTRA_CA_CERTS, OPENSSL_CONF, and any *proxy*-matching env vars were all absent (Get-ChildItem Env: | Where-Object Name -match "..." returned nothing).
5. System/WinHTTP proxy — Confirmed disabled:
   复制

   ProxyEnable = 0, ProxyServer = (empty), AutoConfigURL = (empty)
   netsh winhttp show proxy → Direct access (no proxy server).

6. Corrupted local Lens state — Fully closed Lens (verified no Lens.exe / lens-k8s-proxy.exe processes running), renamed %APPDATA%\Lens out of the way, let Lens regenerate it from scratch, re-ran the "Local Kubeconfigs" onboarding step. Same error, same clusterId format, same message.
7. Stale/duplicate CA certs in the Windows cert store — Found that the Windows cert store (Cert:\CurrentUser\Root, Cert:\LocalMachine\Root, and the \CA stores) had accumulated 126 certificates all named O=Lens, CN=Lens Certificate Authority with different keys/validity windows, apparently one new one added on every connection attempt without cleanup of the old ones. Deleted all 126, confirmed store was clean (count = 0). On the very next Lens launch (no cluster connect yet), 6 new duplicate CA certs were created on a single startup. Connection attempt after this still failed with the identical error.
8. Version rollback — Uninstalled 2026.6.260931-latest completely and installed the previous stable release, 2026.5.181248-latest, from the official download page. Same error, identical error signature. This rules out a regression isolated to the June release — the bug (or its trigger condition) predates at least one full release cycle, or is triggered by something outside the app bundle itself (e.g., persisted local state format, or the growing cert-store pollution described in point 7, which a version rollback does not clean up).
9. OS-level crypto cache — Did a full Windows restart (not just app restart) to rule out a stale CryptSvc cache, then re-cleaned the Lens CA certs immediately after boot and reconnected. Same error persisted.

Suspected root cause

Given points 3 and 7, our working theory: Lens's internal proxy (lens-k8s-proxy) generates a new self-signed CA certificate on every connection cycle and installs it into the Windows certificate store, but the in-memory trust list used by the Node.js HTTPS client validating the proxy connection is loaded from a system-cert snapshot taken at process start (see main log: lens-core-main:setup-system-ca step, 600+ ms). If the proxy's TLS server certificate for the current session was signed by a CA generated after that snapshot was taken (or a stale/duplicate one is picked instead of the matching one), the client-side validation fails with exactly the self signed certificate error reported here — even though the certificate is legitimately Lens's own, not an MITM artifact. The steady accumulation of duplicate Lens Certificate Authority entries (126 observed, 6 more added per subsequent launch) supports this: the app is not deduplicating/pruning its own generated CAs, and whichever one ends up used to sign the live proxy cert may not be the one present in the in-memory trust snapshot the validator checks against.

Steps to reproduce (best effort)

We were not able to find a clean reproduction from a fresh machine — this seems to require the CA cert store to have accumulated enough duplicate/mismatched Lens Certificate Authority entries and/or a particular persisted-state condition to trigger, which likely explains why it "suddenly" started happening after the app had been used normally for a while. We're happy to provide further diagnostics (full lens-main.log / lens-renderer-root-frame.log, cert store dumps) on request.

Full main-process log excerpt

info:    [INTERNAL-PROXY-MAIN]: Proxy server has started at 127.0.0.1:63805
info:    Testing LensProxy connection ...
info:    LensProxy connection OK
...
info:    [CLUSTER-MANAGER-MAIN]: Ensuring cluster connection is active { clusterId: '83bdbf85e64c99d479d0ee0a006ace5f', connectionStatus: 'disconnected' }
info:    [INTERNAL-PROXY-MAIN]: Connection Update { update: 'Starting connection ...', clusterId: '83bdbf85e64c99d479d0ee0a006ace5f' }
info:    [INTERNAL-PROXY-MAIN]: Connection Update { update: 'Authentication proxy started', clusterId: '83bdbf85e64c99d479d0ee0a006ace5f' }
info:    [INTERNAL-PROXY-MAIN]: Port 65006 is being used for clusterId="83bdbf85e64c99d479d0ee0a006ace5f" kube auth proxy
info:    [INTERNAL-PROXY-MAIN]: Connection Update { update: 'Refreshing connection status ...', clusterId: '83bdbf85e64c99d479d0ee0a006ace5f' }
error:   [INTERNAL-PROXY-MAIN]: http proxy errored: Error: self signed certificate; if the root CA is installed locally, try running Node.js with --use-system-ca { url: '/version', closed: false, clusterId: '83bdbf85e64c99d479d0ee0a006ace5f' }
error:   [CLUSTER-MANAGER-MAIN]: Failed to connect to clusterId="83bdbf85e64c99d479d0ee0a006ace5f": Error: Failed to GET "https://127.0.0.1:63805/83bdbf85e64c99d479d0ee0a006ace5f/version": Internal Server Error (500)

Impact

Complete inability to use Lens Desktop for cluster management on this machine — kubectl-based tools remain the only workaround. Happy to provide any additional diagnostics.