tls-util: add a rustls connector for tokio-postgres - #39430

The comment at :133-136 says the OpenSSL connector also trusts the default verify paths. That holds under cargo, but not in the shipped binaries. OpenSSL is vendored (Cargo.toml:445), so its default paths point at /usr/local/ssl, which does not exist in distroless-prod-base. Nothing in the tree sets SSL_CERT_FILE for environmentd or clusterd. test/aws-glue-schema-registry/mzcompose.py:327 and #39432 both record that vendored OpenSSL misses the image's ca-certificates. rustls_native_certs::load_native_certs() goes through openssl_probe::probe() instead, which finds /etc/ssl/certs/ca-certificates.crt (copied into that image).

The tests can't see the difference because cargo exports SSL_CERT_FILE=/usr/lib/ssl/cert.pem and SSL_CERT_DIR=/usr/lib/ssl/certs to every child process, so OpenSSL loads the system bundle under cargo test/nextest. I cleared both variables, set sslrootcert to a fresh private CA, and handshook with s3.amazonaws.com:443 as host my-private-db.internal:

• require: openssl Err("unable to get local issuer certificate"), rustls Ok(())
• verify-ca: openssl Err(...), rustls Ok(())

libpq rejects this combination for the same reason: sslrootcert=system with any mode weaker than verify-full is an error.

Fix: when sslrootcert is set, build the root store from it alone. Load native roots only when no sslrootcert is given, and only for verify-full, so a chain check without a hostname check never runs against public roots. Add a test that clears SSL_CERT_FILE/SSL_CERT_DIR before comparing the connectors, or the equivalence test keeps running against the cargo environment.

PostgreSQL's documented self-signed recipe is openssl req -new -x509 -subj "/CN=dbhost...", used as both server cert and sslrootcert. With the default openssl.cnf it produces a v3 certificate with CA:TRUE and no SAN (checked with OpenSSL 3.5). webpki returns CaUsedAsEndEntity for it (rustls-webpki verify_cert.rs:449). NoHostnameVerifier only maps name errors, so the handshake fails. Probe against an OpenSSL test server using such a certificate as sslrootcert, host localhost:

• require, verify-ca, verify-full: openssl Ok(()), rustls Err(... CaUsedAsEndEntity)

The documented CA-signed recipe (openssl x509 -req with no extfile) gives a server certificate with only a CN. OpenSSL's X509_check_host falls back to the CN when no DNS SAN is present, and webpki checks SANs only:

• CN-only leaf, verify-ca: both Ok(())
• CN-only leaf, verify-full: openssl Ok(()), rustls Err("certificate not valid for name \"localhost\" ... subjectAltName")

ssl_modes_verify_the_same_as_openssl only uses CA-issued leaves with a DNS SAN, so it passes despite these differences. Either handle these certificate shapes, for example by trusting an exact sslrootcert match for a self-signed leaf, or document the stricter behavior and surface it before callers switch.

webpki applies nameConstraints only to SAN entries and the subject as a directoryName (rustls-webpki 0.103 subject_name/mod.rs, check_name_constraints). Its comment there says it does not support CN-IDs. OpenSSL checks the CN of a leaf with no DNS SAN against DNS constraints (NAME_CONSTRAINTS_check_CN in x509_vfy.c, "If EE certificate check commonName too"). This affects both roots the connector can trust: an enterprise sslrootcert with a constrained issuing CA, and the platform bundle used by verify-full with no sslrootcert, which can include technically constrained subordinate CAs held outside a CA.

I checked this at dfe0bfe with a chain of root, then an intermediate with nameConstraints=critical,permitted;DNS:allowed.example, then a leaf with CN=victim.example and no SAN. The test used verify-full and host victim.example:

• sslrootcert = root: openssl Err("permitted subtree violation"), rustls Ok
• no sslrootcert, SSL_CERT_FILE = root: openssl Err("permitted subtree violation"), rustls Ok
• control, leaf CN=db.allowed.example: both Ok
• control, leaf with SAN DNS:victim.example: both Err (rustls NameConstraintViolation)

Fix: skip the CN fallback when the server's intermediates or any trust anchor carry a nameConstraints extension. Webpki does not expose which path it chose, and treating any constraint as disqualifying is safe. Alternatively, check the CN against those DNS subtrees yourself. The pinned branch is not affected, because no issuer sits above a pinned certificate. A case like the first one above, added to postgres_recipe_certs_verify_the_same_as_openssl, would cover this.