fix: import Windows root CA certs into WSL before CLI install (fix curl exit 60)#693
fix: import Windows root CA certs into WSL before CLI install (fix curl exit 60)#693jkf87 wants to merge 2 commits into
Conversation
In corporate / enterprise environments, HTTPS traffic is often
intercepted by a proxy that presents a self-signed or enterprise-issued
root certificate. The freshly-created OpenClawGateway WSL distro does
not know about these corporate CAs, so curl fails with exit code 60
("SSL certificate problem: self-signed certificate in certificate chain")
when downloading the install-cli.sh script, and setup aborts.
Add ImportWindowsCaCertsStep (runs between ValidateWslLockdownStep and
InstallCliStep) that:
1. Reads every trusted root CA from the Windows LocalMachine\Root cert
store using .NET's X509Store API.
2. Serialises them as a PEM bundle, Base64-encodes the bundle, and pipes
it into the WSL distro via printf | base64 -d (avoids heredoc/quoting
issues).
3. Writes the bundle to /usr/local/share/ca-certificates/windows-root-ca.crt
and runs update-ca-certificates so every subsequent process (curl,
Node.js, openssl) trusts the corporate CAs automatically.
The step is intentionally non-fatal: if the cert store is unreadable,
empty, or update-ca-certificates fails for any reason, a warning is
logged and setup continues (so the change has no impact on machines
that don't have a corporate proxy).
Fixes: setup step install-cli failing with curl exit 60 on corporate
networks that perform SSL inspection.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
Codex review: needs real behavior proof before merge. Reviewed June 4, 2026, 11:57 PM ET / 03:57 UTC. Summary Reproducibility: no. high-confidence live reproduction was established in this review for the original corporate-proxy failure; the PR body reports it but provides no after-fix proof. Source inspection gives a clear reproduction path for the introduced command-size failure because the full root bundle is placed in the single Review metrics: 2 noteworthy metrics.
Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Preserve the enterprise CA repair, but stream or chunk the PEM data into WSL, make the default trust-store policy explicit, and require redacted setup logs for both corporate-proxy and normal-network runs. Do we have a high-confidence way to reproduce the issue? No high-confidence live reproduction was established in this review for the original corporate-proxy failure; the PR body reports it but provides no after-fix proof. Source inspection gives a clear reproduction path for the introduced command-size failure because the full root bundle is placed in the single Is this the best way to solve the issue? No. Mirroring Windows root CAs may be the right repair, but this implementation should avoid command-argument-sized payloads and needs maintainer approval for the default TLS trust behavior. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model gpt-5.5, reasoning high; reviewed against 99efc50cbc22. Label changesLabel changes:
Label justifications:
Evidence reviewedSecurity concerns:
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
clawsweeper
Bot
added
rating: 🧂 unranked krab
Addresses review finding: the previous approach embedded the full base64-encoded PEM bundle in the bash -c argument passed to wsl.exe, which could exceed the Windows process argument size limit (~32 KB) on machines with a large root-CA store. Changes: - Add stdinInput parameter to ICommandRunner.RunInWslAsync and CommandRunner.RunInWslAsync so callers can pipe data into WSL without inflating the command-line argument. - ImportWindowsCaCertsStep now passes the raw PEM bundle via stdin; the bash script uses `cat > /path/to/cert.crt` to write it, keeping the command-line argument small regardless of cert-store size. - Update FakeCommandRunner in tests to implement the new interface signature. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Response to ClawSweeper reviewThanks for the detailed review. Addressed all three P1 items: [P1] Command-line size fix → done (commit b0bc8c4)Replaced the base64-in-
[P1] Real behavior proof (before fix)Environment: Windows 11 Home 10.0.26200, corporate network with SSL inspection proxy, OpenClawTray setup Setup log ( The corporate proxy injects a self-signed root CA. The fresh Manual verification that the fix resolves it (Ubuntu WSL — same base distro, same network): The install script downloads successfully after the CA import. [P1] Default trust model / security concernThis is a fair security question. The current behavior is intentionally default-on because:
That said, I'm happy to defer to maintainer judgment on whether this should be opt-in (e.g. a @clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. Re-review progress:
|
All three P1 items from the original ClawSweeper review have been addressed: 1. Command-line size fix (commit 2. Real behavior proof 3. Trust model Happy to add a |
1 participant
Problem
On corporate / enterprise networks, HTTPS traffic is inspected by a proxy
that presents a self-signed or enterprise-issued root certificate.
The freshly-created
OpenClawGatewayWSL distro has no knowledge of thesecorporate CAs, so
curlfails with:This causes the
install-clisetup step to abort with exit code 60, andsetup rolls back entirely.
Reproduced on Windows 11 with a corporate network proxy (SSL inspection enabled).
Fix
Add
ImportWindowsCaCertsStep, inserted betweenValidateWslLockdownStepand
InstallCliStepin the setup pipeline.The step:
LocalMachine\Rootcertificate store via .NET'sX509StoreAPI and exports all trusted root CAs as a PEM bundle.printf '%s' '...' | base64 -d,writes it to
/usr/local/share/ca-certificates/windows-root-ca.crt,and runs
update-ca-certificates.After this step,
curl, Node.js, and OpenSSL inside the distro alltrust the same root CAs as the host Windows machine — including any
corporate / enterprise CAs — so the
install-clidownload succeeds.The step is non-fatal: if the cert store is unreadable, returns no
certs, or
update-ca-certificatesfails for any reason, a warning islogged and setup continues normally. This ensures zero regression on
machines without a corporate proxy.
Test plan
SetupPipelineTests.BuildDefaultSteps_IncludesCurrentSetupFlowupdated: step count 18 → 19, ordering assertion (ImportWindowsCaCertsStepimmediately beforeInstallCliStep) added.install-clistep should succeed.🤖 Generated with Claude Code