verify-ca without an explicit ssl_ca file silently falls back to platform trust (builtin errors instead)

[aesslinger]

Summary

build_tls_connector's verify-ca/verify-full handling only takes its dedicated cert-validation path when ssl_ca is actually set:

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

if needs_cert_validation {
    if let Some(ca_path) = user_ca {
        // ...VerifyCaCertVerifier / WebPkiServerVerifier branches...
    }
}

// falls through here when ssl_mode is verify-ca/verify-full but ssl_ca is unset
let builder = rustls::ClientConfig::builder()
    .with_platform_verifier()
    ...

So verify-ca with no ssl_ca file configured silently falls through to with_platform_verifier() — full OS-trust-store validation, no error.

Builtin's actual behavior (for reference)

src-tauri/src/pool_manager.rs's build_postgres_tls_connector, "verify-ca" branch:

"verify-ca" => {
    // Validate chain, skip hostname. Requires an explicit CA file —
    // platform roots are not used (macOS EKU check rejects them).
    let ca_path = user_ca.ok_or_else(|| {
        "verify-ca mode requires an explicit CA file via the connection's \
        CA Certificate field. On macOS, platform root certificates are \
        not compatible with strict EKU checks. For automatic platform \
        trust, use verify-full instead."
            .to_string()
    })?;
    ...
}

The builtin errors with a clear message if verify-ca has no CA file — it never falls back to platform trust for this mode. Only verify-full is designed to optionally use platform trust when no CA is given (that's the documented distinction between the two modes: use verify-full if you want automatic OS-trust-store validation).

Impact

A user who selects verify-ca but forgets (or doesn't realize they need) to also set ssl_ca silently gets verify-full-like behavior (platform-trust validation) instead of a clear error telling them what's missing. Not a security hole in the sense of accepting untrusted certs — platform trust is still some validation — but it's a behavioral divergence from the builtin and a worse user experience (silent substitution instead of actionable error).

Discovery context

Found while planning the fix for #44 (ssl_mode=require incorrectly validating against platform trust) — while tracing which ssl_mode/ssl_ca combinations currently reach the with_platform_verifier() fallback branch. Distinct from both #43 and #44: this is about verify-ca specifically missing its own CA-required guard, not about require's cert-validation logic or SslMode protocol enforcement. Confirmed structurally present in the current code as of main post-#45; not yet checked whether it predates recent PRs, but the code path itself (needs_cert_validation/user_ca structure) has existed since #40 at the latest.

Proposed fix

In build_tls_connector, when ssl_mode == Some("verify-ca") and user_ca is None, return an error matching the builtin's message (or an equivalent one specific to this plugin's "CA Certificate field" terminology), instead of falling through to the platform-verifier branch. verify-full without ssl_ca should continue to use the platform verifier — that part is already correct and matches the builtin.

[aesslinger]

Implementation plan

Fix

In build_tls_connector (src/client.rs), add an early error when ssl_mode == Some("verify-ca") and user_ca is None — before the needs_cert_validation block currently falls through silently to with_platform_verifier(). Matches the builtin's own guard in build_postgres_tls_connector, adapted to this plugin's param-name-based error convention (this plugin references ssl_cert/ssl_key by name in existing errors, not UI field labels, since these come from JSON params, not a form):

if params.ssl_mode.as_deref() == Some("verify-ca") && user_ca.is_none() {
    return Err(
        "verify-ca mode requires an explicit CA file via ssl_ca. Platform \
         root certificates are not used for this mode. For automatic \
         platform trust, use verify-full instead."
            .to_string(),
    );
}

Placed right after computing user_ca/client_auth, before needs_cert_validation's block — verify-full without ssl_ca continues to fall through to with_platform_verifier() unchanged (that's correct, already matches the builtin).

Tests

• Unit test: build_tls_connector with ssl_mode=verify-ca and no ssl_ca returns an Err mentioning ssl_ca/verify-ca — mirrors the existing build_tls_connector_errors_when_ssl_cert_is_set_without_ssl_key-style tests already in client_tests.rs.
• Confirm existing verify-ca-with-ssl_ca tests (verify_ca_cert_verifier_*, build_tls_connector_verify_ca_*) are unaffected.
• Manual live check: reuse the same two local Podman fixtures from ssl_mode=require/verify-ca/verify-full silently falls back to plaintext (deadpool Config.ssl_mode never set) #43/ssl_mode=require validates the server certificate against the platform trust store (should skip validation entirely) #44/fix: ssl_mode=require/verify-ca/verify-full silently allows plaintext #45 (non-SSL on 54320, self-signed-TLS on 55432) — confirm verify-ca with no ssl_ca now returns this new, clear error instead of the generic platform-verifier TLS-handshake failure it silently produced before.

Verification

cargo test --lib --bins, cargo clippy --all-targets -- -D warnings, cargo fmt --all -- --check, cargo build --release, plus the manual live check above. CHANGELOG entry appended to the existing ### Fixed [Unreleased] section.

Branch: fix/verify-ca-requires-explicit-ca-file, off current main (includes #47).

[aesslinger]

Fixed in #48 — added the same explicit-CA-required guard the builtin has, adapted to this plugin's error-message convention. Verified live against the self-signed-cert SSL instance: verify-ca without ssl_ca now returns a clear, actionable error instead of a confusing generic TLS handshake failure. verify-full and require confirmed unaffected.