Summary

TLS support currently hardcodes ring as the rustls crypto provider. Some deployment environments require the use of platform-approved or FIPS-validated cryptographic libraries (e.g., OpenSSL). We should introduces feature flags that allow users to select their preferred rustls CryptoProvider at compile time.

Motivation

• Compliance: Certain regulated environments do not permit the use of ring and require OpenSSL or other approved crypto libraries.
• Flexibility: Different platforms and deployment targets have different crypto backend preferences. Users should be able to choose without forking the project.
• FIPS support: The rustls-openssl crate offers a fips feature for environments that require FIPS 140 validated cryptography.

Proposed Changes

Introduce three mutually exclusive feature flags for selecting the rustls crypto backend:

Scope

• Add rustls-openssl as an optional workspace dependency
• Remove hardcoded ring feature from rustls and tokio-rustls workspace deps
• Replace the one direct ring::sign API call in tls_utils.rs with the provider-agnostic CryptoProvider::get_default() API
• Add install_crypto_provider() helper to centralize provider initialization
• Deduplicate crypto provider init in main.rs by delegating to install_crypto_provider() instead of inlining the same #[cfg] logic.
• Enable tonic/tls-native-roots for crypto-openssl to provide client-side gRPC TLS without pulling in ring
• Update test infrastructure to use the selected provider
• Switch reqwest from rustls feature to rustls-no-provider in otap and contrib-nodes crates (see below)

Direct reqwest usage

The otap and contrib-nodes crates depend directly on reqwest 0.13 with the rustls feature, which hardcodes aws-lc-rs as the crypto backend. This needs to change:

• Switch from reqwest feature rustls -> rustls-no-provider so that reqwest uses whichever CryptoProvider has been globally installed (ring, aws-lc-rs, or OpenSSL depending on the selected crypto-* feature flag).
• No changes are needed in reqwest itself - it already supports the rustls-no-provider feature for this use case.

What does NOT change

• All existing TLS functionality (certificate loading, hot-reload, mTLS, etc.)
• The public API surface

Transitive ring dependencies

After this change, ring is fully eliminated from the direct dependency chain when using crypto-openssl. However, ring still appears transitively through upstream crates:

• opentelemetry-otlp (0.31.0): Its tls feature hardcodes tonic/tls-ring, and it depends on reqwest ^0.12 which activates rustls-tls-webpki-roots -> ring. The opentelemetry-rust main branch
  has partial fixes (tls-ring/tls-aws-lc feature split, reqwest updated to 0.13). However, to fully support OpenSSL as a crypto backend, additional work is needed: opentelemetry-otlp should offer a provider-agnostic TLS option (similar to reqwest's rustls-no-provider) so that consumers using rustls-openssl can install their provider globally without the exporter forcing a specific backend.
  Note: tonic 0.14 already supports provider-agnostic TLS via its tls-native-roots feature, which enables TLS plumbing and OS certificate store without pulling in ring or aws-lc-rs. The crypto-openssl feature flag uses this to provide full client-side gRPC TLS with OpenSSL today.
• weaver (pinned at v0.17.0): Pulls in ring through three transitive paths: gix (via gix-transport -> reqwest 0.12), ureq (which depends on rustls with ring), and jsonschema (via reqwest 0.12). To fully eliminate ring, weaver would need to update these dependencies to versions that either use reqwest 0.13 with rustls-no-provider or native-tls, rather than hardcoding ring as the crypto backend. The fix on this repo's side is to bump the weaver version once a newer release is available with these updates
  Note: weaver is only used to power the fake data generator - a dev/testing/benchmarking tool for generating synthetic telemetry data. It is not a production pipeline component and does not process customer or internal data.

These will be tracked and resolved as the upstream crates release updates.

References

• rustls-openssl - OpenSSL-backed CryptoProvider for rustls
• rustls CryptoProvider docs
• open-telemetry/opentelemetry-rust#2704 — Related upstream issue for pluggable TLS in opentelemetry-otlp