Custom TLS configuration requires the `rustls-tls` or `nativ

Error message

Custom TLS configuration requires the `rustls-tls` or `native-tls` feature

What it means

This build of goose was compiled without either TLS backend feature (rustls-tls or native-tls), so the real configure_tls that loads client identities and CA bundles does not exist; only this #[cfg(not(...))] stub compiles. The stub's one job is to fail loudly when a caller asks for custom TLS (TlsConfig::is_configured() = client_identity or ca_cert_path set) on a TLS-less binary, instead of silently ignoring your certificates.

Source

Thrown at crates/goose-providers/src/api_client.rs:379

            }

            // Load CA certificates
            let ca_certs = tls_config.load_ca_certificates()?;
            for ca_cert in ca_certs {
                client_builder = client_builder.add_root_certificate(ca_cert);
            }
        }
        Ok(client_builder)
    }

    /// Reject custom TLS settings when goose is compiled without a TLS backend.
    #[cfg(not(any(feature = "rustls-tls", feature = "native-tls")))]
    fn configure_tls(
        client_builder: reqwest::ClientBuilder,
        tls_config: &TlsConfig,
    ) -> Result<reqwest::ClientBuilder> {
        if tls_config.is_configured() {
            return Err(anyhow::anyhow!(
                "Custom TLS configuration requires the `rustls-tls` or `native-tls` feature"
            ));
        }
        Ok(client_builder)
    }

    pub fn with_headers(mut self, headers: HeaderMap) -> Result<Self> {
        self.default_headers = headers;
        self.rebuild_client()?;
        Ok(self)
    }

    pub fn with_query(mut self, params: Vec<(String, String)>) -> Self {
        self.default_query = params;
        self
    }

    pub fn with_header(mut self, key: &str, value: &str) -> Result<Self> {

View on GitHub (pinned to 3810898a74)

Solutions

Re-enable a TLS backend: add default-features = true, or features = ["rustls-tls"] (or "native-tls") to the goose-providers dependency / cargo build --features rustls-tls
If TLS customization genuinely isn't needed, remove the client-cert/CA config so is_configured() is false
For downstream crates: check cargo tree -e features on goose-providers to confirm which TLS feature survives feature unification

Example fix

# before
# Cargo.toml
goose-providers = { version = "...", default-features = false }  # no TLS feature

# after
goose-providers = { version = "...", default-features = false, features = ["rustls-tls"] }

Defensive patterns

Strategy: validation

Validate before calling

fn tls_backends_compiled_in() -> bool {
    cfg!(any(feature = "rustls-tls", feature = "native-tls"))
}
// before configuring:
if tls.is_configured() && !tls_backends_compiled_in() {
    eprintln!("TLS customization ignored: build lacks rustls-tls/native-tls");
    // either skip TLS config or abort, matching your policy
}

Try / catch

// Compile-time guard so misconfigured feature sets fail the build, not first request:
#[cfg(all(not(any(feature = "rustls-tls", feature = "native-tls"))))]
const _: () = { /* optional: emit a build warning via build.rs instead */ };

Prevention

Pin the feature explicitly in Cargo.toml (features = ["rustls-tls"]) instead of relying on default-feature inheritance
Run cargo tree -e features -p goose-providers in CI to assert a TLS feature survives unification
If shipping a TLS-optional binary, gate the TLS settings UI/env parsing on the same cfg so users can't reach this error

When it happens

Trigger: Building goose-providers with --no-default-features (or a feature set that drops rustls-tls/native-tls) while configuration or code sets a client cert/key pair or a CA cert path, e.g. GOOSE_TLS_* settings or TlsConfig::with_ca_cert(...).

Common situations: Downstream crates depend on goose-providers with a trimmed feature list to slim builds; distro packaging compiles with default-features=false; users then enable corporate-proxy CA settings that previously worked in the official binary.

Understand the failure class

SSL/TLS and certificate errors — how TLS handshakes and certificate validation fail.

Related errors

AI-assisted analysis of aaif-goose/goose@3810898a74 (2026-08-16). Data as JSON: /api/errors/12070ccfe6f35371. Report an issue: GitHub.