Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

helm (Go) fails TLS through Cortex proxy on macOS — CA not in System keychain

Chiusa
  • Qualcosa non va?
#1,348 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #1357 di @huang195 — integrata
  • #1358 di @huang195 — integrata

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
18/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go, helm, macos, shell
Ambito
cli, devops, security

Direzione di ricerca

The payload names no source files, only install.sh and the agentop CLI, plus the ~/.cortex/ca/bundle.crt path the env vars point at. Start by reading how install.sh and agentop set HTTPS_PROXY and the CA variables, and reproduce with helm repo update behind the proxy. Done means a maintainer has chosen between the keychain change, a proxy bypass, or another supported CA path, and the chosen approach is implemented.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

Go-based CLI tools (here: helm) fail TLS verification when their traffic is routed through the Cortex proxy on macOS, because they do not consult the *_CA_BUNDLE / SSL_CERT_FILE environment variables Cortex sets, and the Cortex bridge CA is not in the macOS System keychain that Go verifies against.

Filed as a blank issue per the Laptop-feedback template's guidance ("a Helm or platform problem — open a blank issue instead"). Raised with a Cortex maintainer, who suggested filing with details.

Where it fails

On the local machine, not the cluster. A Python CLI shells out to the local helm binary, which fetches public Helm chart repos (e.g. https://llm-d-incubation.github.io/llm-d-infra/) over the internet via the local Cortex proxy. The cluster API path (kubectl/oc) is unaffected.

Symptom

helm repo update llmDInfra
Get "https://llm-d-incubation.github.io/llm-d-infra/index.yaml":
  tls: failed to verify certificate: x509: certificate signed by unknown authority

Reproduces both inside the CLI and when helm repo update is run standalone in the same shell.

Works vs. doesn't

  • curl -sSI https://llm-d-incubation.github.io/llm-d-infra/index.yaml → HTTP/2 200 (curl honors CURL_CA_BUNDLE).
  • helm repo update → TLS failure.

Root cause (hypothesis)

Cortex sets HTTPS_PROXY=http://127.0.0.1:47600 plus CURL_CA_BUNDLE / REQUESTS_CA_BUNDLE / SSL_CERT_FILE → ~/.cortex/ca/bundle.crt (valid, 129 certs). curl- and Python-based tools trust the bridge CA via those vars. Go-based tools (helm, and likely oc/kubectl plugins, gh in some builds) do not read *_CA_BUNDLE, and on macOS Go verifies against the System keychain rather than SSL_CERT_FILE — where the Cortex CA is absent. So any Go tool doing outbound TLS through the proxy fails.

Options considered (none applied)

  1. Add the Cortex CA to the macOS System keychain (security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ~/.cortex/ca/bundle.crt) — fixes all Go tools, but is a sudo, machine-wide trust change.
  2. Bypass the proxy for the helm step (env -u HTTPS_PROXY ...) — loses Cortex token visibility for those calls.

Questions

  1. Is adding the bridge CA to the macOS System keychain the intended/supported fix for Go tools, and if so should install.sh / agentop do it (or offer it)?
  2. Is there a supported way for Go/helm to pick up the CA without a system-wide keychain change?
  3. Is per-tool proxy bypass acceptable to Cortex's accounting model?

Environment

  • OS: Darwin arm64
  • Cortex: agentop v0.8.0
  • agentop service status: healthy; TLS bridge CA ~/.cortex/ca/ca.crt (minted 2026-09-14), env vars point at ~/.cortex/ca/bundle.crt
  • helm: v4.2.3+g43e8b7f (Go go1.25.1 darwin/arm64)
  • Agent: Claude Code, claude-opus-4-8
Lingua principale
Go
Stelle
16
Fork
41
Merge medio
11h 11m
PR unite (30g)
270

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di rossoctl/cortex

Tutte le issue di rossoctl/cortex

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.