fix: use system CAs during OIDC enrollment#1014
Closed
seantechco wants to merge 1 commit intoopenziti:mainfrom
Closed
fix: use system CAs during OIDC enrollment#1014seantechco wants to merge 1 commit intoopenziti:mainfrom
seantechco wants to merge 1 commit intoopenziti:mainfrom
Conversation
When enrolling via URL (-u), the SDK downloads the Ziti internal CA from /.well-known/est/cacerts, then creates a TLS context trusting ONLY that CA. This breaks reconnection to the enrollment endpoint when it uses a publicly-trusted certificate (e.g., Let's Encrypt behind a reverse proxy). The fix: use the system CA bundle (NULL) during enrollment so the SDK can verify both publicly-trusted enrollment endpoints and Ziti internal CA endpoints discovered via /version. The Ziti CA is still saved in the identity config for post-enrollment runtime use. Fixes enrollment failures in split-endpoint deployments where: - enroll.example.com presents a Let's Encrypt cert - ziti.example.com presents a Ziti internal CA cert - Both are discovered via /version apiBaseUrls Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Member
|
this sounds like you're trying to address controller misconfiguration. this change will (most likely) break standard installations and (definitely) enrollment on controllers that do not have LE certs |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When enrolling via URL (
ziti-edge-tunnel enroll -u), the SDK downloads the Ziti internal CA from/.well-known/est/cacerts, then creates a TLS context trusting only that CA atziti_enroll.c:403. This breaks reconnection to the enrollment endpoint when it uses a publicly-trusted certificate (e.g., Let's Encrypt behind a reverse proxy).Root Cause
In
well_known_certs_cb()at line 403:This replaces the TLS context with one that trusts only the Ziti CA. The subsequent
ziti_ctrl_init()fires a/versionrequest to the enrollment controller URL. If that endpoint presents a publicly-trusted cert (Let's Encrypt), the TLS handshake fails because the Ziti CA doesn't trust Let's Encrypt.Fix
Use the system CA bundle (
NULL, 0) during enrollment so the SDK can verify both:/version)The Ziti CA is still saved in
er->cfg.id.cafor the identity config file, ensuring post-enrollment runtime connections use the correct trust chain.Reproduction
enroll.example.com) with a Let's Encrypt cert via TLS passthroughziti.example.com) presents the Ziti internal CA cert/versionapiBaseUrlsziti-edge-tunnel enroll -u https://enroll.example.com -i identity.jsonTest Plan
🤖 Generated with Claude Code