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 3 commits into
Conversation
|
Codex review: needs real behavior proof before merge. Reviewed June 9, 2026, 3:05 AM ET / 07:05 UTC. Summary Reproducibility: no. high-confidence current-main reproduction was run in this review. Source inspection plus the contributor's redacted logs show the existing Review metrics: 3 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 detailsBest possible solution: Land the enterprise CA repair only after a maintainer-approved trust policy is explicit and redacted real setup logs cover both corporate SSL-inspection and normal-network installs. Do we have a high-confidence way to reproduce the issue? No high-confidence current-main reproduction was run in this review. Source inspection plus the contributor's redacted logs show the existing Is this the best way to solve the issue? Unclear. Streaming the CA bundle via stdin is the right transport repair, but the default-on root-store mirroring policy and direct setup proof still need maintainer review before this is the best merge path. AGENTS.md: found and applied where relevant. Codex review notes: model gpt-5.5, reasoning high; reviewed against 71d249711d63. 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
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 |
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>
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>
jkf87
force-pushed
the
fix/corporate-ssl-ca-cert-import
branch
from
b0bc8c4 to
29190db
Compare
clawsweeper
Bot
added
rating: 🦪 silver shellfish
2 participants
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