ssl_mode=require validates the server certificate against the platform trust store (should skip validation entirely)

[aesslinger]

Summary

build_tls_connector's own doc comment states: "require forces TLS without certificate validation (matches the builtin driver's require behavior — see src-tauri/src/pool_manager.rs)." The code doesn't do this.

needs_cert_validation only matches "verify-ca" | "verify-full" — require is excluded. So for ssl_mode=require, execution falls through the if needs_cert_validation { ... } block entirely and lands on the final fallback:

let builder = rustls::ClientConfig::builder()
    .with_platform_verifier()
    .map_err(|e| format!("Failed to build platform TLS verifier: {e}"))?;

with_platform_verifier() does validate the server's certificate against the OS trust store — the opposite of "without certificate validation." So require currently behaves like verify-full (full platform-trust validation) instead of like disable/allow/prefer (no validation, just opportunistic/forced TLS).

Builtin's actual behavior (for reference)

src-tauri/src/pool_manager.rs's build_postgres_tls_connector:

"require" => {
    // Force TLS, skip cert validation.
    let verifier = Arc::new(NoCertVerifier::new());
    ClientConfig::builder()
        .dangerous()
        .with_custom_certificate_verifier(verifier)
        .with_no_client_auth()
}

require uses the same NoCertVerifier (accepts any certificate, no validation at all) as disable/allow/prefer — the only thing that changes between those modes and require is whether TLS is attempted at all (handled by SslMode, see #43), not whether the cert is checked.

Impact / reproduction

Found while manually verifying the #43 fix against a real SSL-enabled PostgreSQL instance with a self-signed certificate:

echo '{"jsonrpc":"2.0","id":1,"method":"test_connection","params":{"params":{"host":"127.0.0.1","port":55432,"username":"postgres","password":"password","database":"testdb","ssl_mode":"require"}}}' \
  | ./target/debug/postgresql-plugin

Result: {"error":{"code":-32603,"message":"Connection failed: Error occurred while creating a new object: error performing TLS handshake"}}

Expected (per the doc comment and the builtin's behavior): require should connect successfully — the whole point of require mode (vs. verify-full) is "encrypt the connection, but don't bother validating who's on the other end" — the standard use case being self-signed certs, private CAs the user hasn't configured ssl_ca for, or any server the user trusts by network topology rather than PKI.

Discovery context

Confirmed via git log/git show 9986b1e that this bug has been present since client.rs was first staged (#3) — not a regression from #35/#37/#40/#41/#42, and distinct from #43 (different root cause: cert validation logic, not protocol-level SslMode enforcement), even though both live in build_tls_connector/TLS setup and were found back-to-back while testing #43.

Proposed fix

Add a no-op/accept-all certificate verifier (mirroring the builtin's NoCertVerifier) and route require mode to it instead of falling through to with_platform_verifier(). Something like:

let needs_cert_validation = matches!(
    params.ssl_mode.as_deref(),
    Some("verify-ca" | "verify-full")
);

if needs_cert_validation {
    // ...existing verify-ca / verify-full logic...
}

if params.ssl_mode.as_deref() == Some("require") {
    // no validation, matches builtin's NoCertVerifier
    ...
}

// remaining fallback (disable/allow/prefer/unset) — platform verifier is
// arguably also wrong here per the builtin's NoCertVerifier for these
// modes; worth checking during the fix whether this fallback branch needs
// the same treatment, or whether it's intentionally different since those
// modes don't force TLS to begin with.

Needs a rustls::client::danger::ServerCertVerifier impl that unconditionally accepts (or a Debug-safe wrapper around rustls::client::WebPkiServerVerifier-style dangerous-but-empty checks) — check if rustls's ecosystem already has one exposed (e.g. behind a feature flag) before hand-rolling one.

Add a unit test constructing the verifier directly and asserting it accepts an arbitrary self-signed cert (mirroring the pattern used for VerifyCaCertVerifier's tests in src/client_tests.rs), plus a live-DB test against an SSL-enabled fixture with a self-signed cert (the repo doesn't currently have one in CI — .github/workflows/ci.yml's Postgres fixture runs without SSL at all).

[aesslinger]

Implementation plan

Builtin's exact reference behavior

src-tauri/src/pool_manager.rs's build_postgres_tls_connector uses a NoCertVerifier for disable/allow/prefer/require — it unconditionally accepts any certificate (no chain validation, no hostname check, and no TLS 1.2/1.3 signature verification either):

struct NoCertVerifier {
    supported: rustls::crypto::WebPkiSupportedAlgorithms,
}
impl NoCertVerifier {
    fn new() -> Self {
        let provider = CryptoProvider::get_default().expect("rustls CryptoProvider not installed");
        Self { supported: provider.signature_verification_algorithms }
    }
}
impl ServerCertVerifier for NoCertVerifier {
    fn verify_server_cert(&self, ..) -> Result<ServerCertVerified, TlsError> {
        Ok(ServerCertVerified::assertion())
    }
    fn verify_tls12_signature(&self, ..) -> Result<HandshakeSignatureValid, TlsError> {
        Ok(HandshakeSignatureValid::assertion())
    }
    fn verify_tls13_signature(&self, ..) -> Result<HandshakeSignatureValid, TlsError> {
        Ok(HandshakeSignatureValid::assertion())
    }
    fn supported_verify_schemes(&self) -> Vec<rustls::SignatureScheme> {
        self.supported.supported_schemes()
    }
}

Per this repo's CLAUDE.md parity mandate, porting this faithfully — including the full signature-check bypass (more permissive than VerifyCaCertVerifier's chain-only bypass), since that's the builtin's actual, presumably-intentional choice for this mode. TLS's encryption still applies; what's given up is peer authentication, which is the documented tradeoff of sslmode=require (libpq semantics).

Note: disable/allow/prefer never reach build_tls_connector at all in this plugin (needs_tls() only returns true for require/verify-ca/verify-full) — so this fix only needs to wire NoCertVerifier into the require branch.

Fix

In src/client.rs:

1. Add a NoCertVerifier struct implementing rustls::client::danger::ServerCertVerifier, mirroring VerifyCaCertVerifier's existing style exactly (same crypto-provider lazy-install fallback pattern in ::new(), same trailing verify_tls12_signature/verify_tls13_signature/supported_verify_schemes shape) — but verify_server_cert unconditionally returns Ok(ServerCertVerified::assertion()), and both signature methods unconditionally return Ok(HandshakeSignatureValid::assertion()) (no delegation to rustls::crypto::verify_tls12_signature/verify_tls13_signature).
2. In build_tls_connector, add a branch for ssl_mode == Some("require") using this verifier, placed after the existing needs_cert_validation block and before the final with_platform_verifier() fallback. Thread client_auth through the same Some((certs, key)) => .with_client_auth_cert(...) / None => .with_no_client_auth() pattern already used by the other branches, so mTLS + require still work together.
3. Leave the fallback branch untouched — still correctly reached by verify-ca/verify-full when no ssl_ca is set. (The verify-ca-without-ssl_ca silent-fallback-to-platform-trust discrepancy is a separate issue, filed as verify-ca without an explicit ssl_ca file silently falls back to platform trust (builtin errors instead) #46, out of scope here.)

Tests

• Unit test mirroring VerifyCaCertVerifier's style: construct NoCertVerifier directly, feed it the existing FIXTURE_SERVER_CERT_PEM fixture with a hostname that doesn't match its CN/SAN, assert it's accepted (proves no checking at all, not even the hostname skip VerifyCaCertVerifier does).
• build_tls_connector-level sanity test: ssl_mode=require (no ssl_ca needed) builds successfully.
• Manual live verification against the local Podman SSL-enabled instance (self-signed cert, port 55432) already set up for ssl_mode=require/verify-ca/verify-full silently falls back to plaintext (deadpool Config.ssl_mode never set) #43/fix: ssl_mode=require/verify-ca/verify-full silently allows plaintext #45 — re-run the exact repro from this issue and confirm it now returns success. Also re-check require against the non-SSL fixture (still correctly fails per ssl_mode=require/verify-ca/verify-full silently falls back to plaintext (deadpool Config.ssl_mode never set) #43) and verify-ca/verify-full against both instances for no regression.
• No CI fixture changes — CI has no SSL-enabled Postgres container; unit test + manual live verification is consistent with how fix: verify-ca incorrectly enforces hostname verification #40 verified VerifyCaCertVerifier without adding CI infra.

Verification

cargo test --lib --bins, cargo clippy --all-targets -- -D warnings, cargo fmt --all -- --check, cargo build --release, npx markdownlint CHANGELOG.md, plus the manual live checks above.

Branch: fix/ssl-mode-require-cert-validation, off current main (includes #45).

[aesslinger]

Fixed in #47 — ported NoCertVerifier from the builtin's pool_manager.rs (unconditionally accepts any cert, matching require mode's documented-but-unimplemented behavior). Proved the bug and the fix live against a real self-signed-cert SSL-enabled PostgreSQL instance: require failed the handshake before, connects successfully after. No regression in verify-ca/verify-full or require against a non-SSL server.