deps: switch reqwest from native-tls to rustls with aws-lc-rs

[jasonhernandez]

Motivation

Move reqwest 0.13 off OpenSSL (native-tls) onto rustls with the aws-lc-rs provider, as part of removing OpenSSL and ring from the tree. Prior art: #35947.

Description

• reqwest uses its rustls feature: aws-lc-rs plus rustls-platform-verifier, which trusts the system store on Linux and macOS.
• sentry switches from transport to reqwest + rustls. transport enables reqwest's native-tls, and reqwest defaults to native-tls whenever it is compiled in, so every client would otherwise stay on OpenSSL.
• mz-ccsr's Identity holds the PEM key and certificates and passes them to rustls. Schema registry connections already take PEM (SSL KEY, SSL CERTIFICATE). The PKCS#12 archive Identity used to build from them was only an internal step for native-tls, so the SQL surface is unchanged. Identity checks that the key matches the certificate, is zeroized on drop, and redacts Debug. It is built from secrets at connect time and never persisted.
• testdrive's --cert still takes a PKCS#12 keystore and converts it to PEM itself. No CI job passes --cert.
• New mz_ccsr::tls::TlsError replaces the native-tls and OpenSSL variants of CsrConnectError. mz-ccsr and mz-storage-types drop native-tls and openssl.
• Still on OpenSSL after this PR: reqwest 0.12 (forced by the iceberg fork's defaults and duckdb), and the MySQL source's PEM to PKCS#12 conversion for mysql_async.

Behavior changes

• On Linux, building a client fails fast if no system CA bundle is present.
• The system trust store is read each time a client is built, which for ccsr means once per schema registry connection.
• Schema registry TLS errors use rustls text, for example invalid peer certificate: UnknownIssuer. The kafka-auth .td files are updated.
• A key that does not match its certificate is rejected with keys may not be consistent: KeyMismatch instead of an OpenSSL PKCS#12 error.
• webpki is stricter than OpenSSL about server certificates. A self-signed CA:TRUE certificate given as its own SSL CERTIFICATE AUTHORITY fails with CaUsedAsEndEntity. Follow-up ccsr: trust a server certificate that exactly matches the configured CA #39459 accepts it by exact match. A certificate with only a CN and no subjectAltName now fails with a name error and must be reissued with a SAN. The same stricter validation applies to COPY FROM URLs and the OIDC issuer fetch, with no exact-match fallback.

Release notes

Schema registry connections and COPY FROM URLs now reject server certificates that identify the host only by common name, without a subjectAltName. If a server uses such a certificate, reissue it with a subjectAltName that matches its hostname before upgrading.

Verification

Locally: bin/fmt, workspace cargo check, clippy on the touched crates, cargo-deny, lint-cargo, and ccsr and testdrive unit tests, including a new test_pem_identity.

CI: PR CI covers kafka-auth (schema registry ssl, ssl-basic, mssl, mssl-basic), testdrive, and the environmentd auth/server and balancerd server tests. Nightly (ci-nightly) covers testdrive-old-kafka-src-syntax, cloudtest and orchestratord.

🤖 Generated with Claude Code

[def-]

QA LLM Review

1. MEDIUM -- Existing schema registry connections break on upgrade when the registry's certificate is one OpenSSL accepts but webpki rejects

Cargo.toml:470

Schema registry TLS moves from OpenSSL to rustls/webpki, which is stricter about server certificates. A registry whose certificate has no subjectAltName (CN only), or which uses a self-signed CA:TRUE certificate supplied as SSL CERTIFICATE AUTHORITY, works today and fails after upgrade. Nothing flags this at upgrade time. Existing Avro sources halt and Kafka sinks fail to start.

Details

I checked this against reqwest 0.13.5, rustls 0.23.45 and rustls-webpki 0.103.15, the versions this PR locks. I used add_root_certificate + resolve, the same setup as ccsr::ClientConfig::build, against openssl s_server, and switched between tls_backend_native() and tls_backend_rustls():

• Leaf signed by a private CA, CN=sr.example.com, no SAN. Native: 200 OK. Rustls: invalid peer certificate: certificate not valid for name "sr.example.com"; certificate is not valid for any names (according to its subjectAltName extension). OpenSSL falls back to the CN when there are no DNS SANs, and webpki does not. keytool -genkeypair -dname CN=... without -ext SAN=... produces this kind of certificate, which is common for self-hosted Schema Registry keystores.
• Self-signed cert from a plain openssl req -x509 (adds CA:TRUE), given as its own CA. Native: 200 OK. Rustls: invalid peer certificate: Other(OtherError(CaUsedAsEndEntity)).

The kafka-auth fixtures (test/test-certs/create-certs.sh) always issue SAN-bearing leaves from a separate CA, so CI does not exercise either case. At runtime CsrConnection::connect is called from the source decoder (src/storage/src/decode.rs:364) and the Kafka sink (src/storage/src/sink/kafka.rs:1423). After a restart the writer-schema cache is empty, so the first fetch fails and the source goes into a halting loop. Librdkafka still uses OpenSSL, so a Kafka connection that uses the same PKI keeps working, which makes the failure confusing. The same stricter validation now also applies to COPY FROM URLs and to the OIDC issuer fetch (src/authenticator/src/oidc.rs:308).

This change is not listed under "Behavior changes". At minimum it needs a release note. A pre-upgrade check or a per-connection fallback would avoid breaking these connections silently.

[antiguru]

Looks good, thank you!

[jasonhernandez]

Addressed: self-signed CA:TRUE certificates given as their own CA are accepted by exact match in #39459. CN-only certificates stay rejected and are now in Behavior changes and Release notes, along with COPY FROM and OIDC.