Repository navigation
Preserve TLS policy errors during custom CA validation - #1964
Conversation
There was a problem hiding this comment.
🟢 Approval recommended
The focused guard preserves other TLS failures, with regression coverage and no unresolved findings.
0 open findings
What changed in this PR
Prevents custom CA validation from overriding unrelated TLS policy errors in the Kubernetes client.
Changes:
- Rebuilds the certificate chain only when chain errors are the sole TLS failure.
- Adds regression coverage for accepting chain-only errors and rejecting combined hostname and chain errors.
| File | Description |
|---|---|
| tests/KubernetesClient.Tests/CertificateValidationTests.cs | Tests custom CA acceptance and hostname mismatch rejection. |
| src/KubernetesClient/Kubernetes.ConfigInit.cs | Restricts custom CA validation to chain-only errors. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
Looks reasonable to me but tests are failing. |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: brendandburns, tg123 The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Summary
Custom CA validation now rebuilds the certificate chain only when
RemoteCertificateChainErrorsis the sole TLS policy error. If a hostname mismatch or missing-certificate error is also present, the callback returnsfalserather than allowing a successful chain rebuild to override those errors.The existing chain-building logic is unchanged. HTTPS and WebSocket connections use the same callback.
Adds a regression test confirming that a certificate signed by a configured custom CA is accepted for chain errors alone and rejected when a hostname mismatch is also reported.
Updates the existing mutual-TLS authentication test to use the certificate fixture's DNS name as
TlsServerName. The mock server listens on a loopback address that does not match the fixture's name; certificate verification remains enabled.Validation
Ran the authentication and certificate-validation tests on .NET 10 in WSL: 21 passed, 0 failed.