azure_core and azure_identity: Issue with rustls-only Configuration

[hegdemohan]

Summary

There's an issue when trying to use azure_core and azure_identity crates with rustls-only TLS configuration without pulling in OpenSSL dependencies.
This issue affects projects that need to avoid OpenSSL for various deployment, security, or licensing reasons.
Any guidance on the correct approach would be really helpful!

Environment

• azure_core Version: 0.25.0
• azure_identity Version: 0.25.0
• Rust Version: 1.88.0
• Cargo Version: 1.88.0
• Operating System: Linux (Ubuntu 24.04.2 LTS on WSL)

The Goal

The objective is to use azure_core and azure_identity crates with rustls for TLS while completely avoiding OpenSSL dependencies in the final binary.

What's Been Tried

Step 1: Using azure_core with feature reqwest_rustls

Cargo.toml:

[package]
name = "azure-rustls-test"
version = "0.1.0"
edition = "2021"

[dependencies]
azure_core = { version = "0.25", default-features = false, features = ["reqwest_rustls"] }

Result: OpenSSL dependencies appear despite explicitly using the reqwest_rustls feature.

Workaround: Using azure_core with reqwest package explicitly

Attepmted to remove the feature from azure_core and added feature rustls-tls-native-roots-no-provider on reqwest directly.

Cargo.toml:

[package]
name = "azure-rustls-test"
version = "0.1.0"
edition = "2021"

[dependencies]
azure_core = { version = "0.25", default-features = false }
reqwest = { version = "0.12", default-features = false, features = ["rustls-tls-native-roots-no-provider"] }

Result: Only openssl-probe is installed which is okay, and no other OpenSSL related libraries are brought in as dependency.

Step 2: Using azure_identity with azure_core and reqwest

Following up on the previous step, now added azure_identity
Cargo.toml:

[package]
name = "azure-rustls-test"
version = "0.1.0"
edition = "2021"

[dependencies]
azure_identity = { version = "0.25", default-features = false }
azure_core = { version = "0.25", default-features = false }
reqwest = { version = "0.12", default-features = false, features = ["rustls-tls-native-roots-no-provider"] }

Result: OpenSSL dependencies appear again.

What the Dependency Tree Shows

With the minimal version of
Cargo.toml:

[package]
name = "azure-rustls-test"
version = "0.1.0"
edition = "2021"

[dependencies]
azure_identity = { version = "0.25", default-features = false }
reqwest = { version = "0.12", default-features = false, features = ["rustls-tls-native-roots-no-provider"] }

Running this command:

cargo tree -f "{p} {f}" | grep reqwest

Reveals that reqwest ends up with both TLS backends:

reqwest v0.12.21 __rustls,__tls,default-tls,json,native-tls,rustls-tls-native-roots-no-provider,stream

It appears that both native-tls and rustls-tls-native-roots-no-provider features are being activated simultaneously.

TL;DR Summary

When using azure_identity or azure_core with specific rustls features, OpenSSL dependencies are still pulled in despite attempts to use rustls exclusively.
The workaround of using azure_core without features and controlling reqwest directly works,
but adding azure_identity breaks this solution by reintroducing OpenSSL dependencies.
This appears to be a feature unification issue where both TLS backends (native-tls and rustls) are being activated simultaneously,
making it impossible to use these Azure crates without OpenSSL dependencies.

Questions

1. Is there a recommended pattern for achieving rustls-only configuration with azure_core and azure_identity?

2. Could there be something wrong in how the features are being configured on these specific crates?

Why This Matters

This situation affects projects that need to avoid OpenSSL because of:

• Deployment constraints - environments where OpenSSL isn't readily available
• Build requirements - situations requiring static linking without OpenSSL runtime dependencies
• Security policies - organizational requirements to avoid certain dependencies

---

Thanks so much for taking the time to look at this!

[alixmacdonald10]

This is also affecting my team.

Has this had any triage?

[RickWinter]

Thank you for reporting this. We are looking into the issue.