[bug] Custom CA validation bypassed when system trust succeeds in ValidateServerCertificate #6800
Description
Package
OpenTelemetry
Package Version
| Package Name | Version |
|---|---|
| OpenTelemetry.Api | 1.8.0 |
| OpenTelemetry | 1.8.0 |
| OpenTelemetry.Exporter.OpenTelemetryProtocol | 1.8.0 |
Runtime Version
net8.0
Description
When OtlpCertificateManager.ValidateServerCertificate is invoked with a custom CA configured (e.g., CaCertificatePath), the method returns true immediately if sslPolicyErrors == SslPolicyErrors.None. This bypasses custom CA pinning and accepts any certificate trusted by the system store.
Example: user configures an internal CA, but an attacker presents a valid publicly trusted cert (Let’s Encrypt/DigiCert), and the connection is accepted. This defeats the expectation that only the custom CA is trusted.
Steps to Reproduce
- Configure OTLP exporter with
internal-ca.crt. - Connect to a server presenting a publicly trusted certificate (not signed by the custom CA).
- Observe that the connection is accepted.
Expected Result
When a custom CA is provided, validation should require the certificate chain to terminate at that CA. Certificates trusted only by the system store should be rejected.
Actual Result
ValidateServerCertificate returns true for any certificate trusted by the system store, even when a custom CA is configured.
Additional Context
Problematic logic returns early on sslPolicyErrors == None and never verifies the custom CA. This is a security issue because it bypasses custom trust restrictions.
Tip
React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.