DBeaver Connection UI and PostgreSQL JDBC Driver: Which SSL/TLS and Authentication Settings Are Authoritative?

A DBeaver connection to PostgreSQL that succeeds locally but fails in production exposes an unresolved integration boundary between DBeaver's connection UI and the underlying PostgreSQL JDBC driver. The goal is to determine whether DBeaver's SSL/TLS and authentication selections are meant to generate a complete, authoritative JDBC property set matching the server's pg_hba.conf and certificate requirements, or whether they function only as defaults that must be supplemented with explicit driver properties for production security.

Several constraints complicate this mapping. DBeaver resolves a specific JDBC driver jar based on its connection settings, and the effective properties sent to the server may differ when values are set through the UI versus entered manually in the driver-properties list. SSL/TLS behavior diverges sharply between environments: development may accept self-signed certificates or password authentication, while production often requires server-certificate validation, client certificates, or a specific TLS version. An SSH tunnel further obscures the boundary by forwarding a local port to the remote host, causing the JDBC driver to validate the tunnel endpoint rather than the database hostname. Driver version sensitivity adds another layer, as DBeaver may bundle or download different driver versions across releases, changing property names or defaults even when server configuration remains unchanged.

Given these factors, should DBeaver treat connection-level SSL and authentication choices as authoritative and synthesize the full driver property set automatically, or should it expose them as overridable defaults that administrators must reconcile manually with explicit JDBC properties? If an SSH tunnel is active, how should certificate hostname validation be aligned with the real database host rather than the forwarded local endpoint? Which verification approach—inspecting DBeaver's effective driver configuration, pinning the driver version, or comparing server-side TLS negotiation logs—most reliably confirms that UI-selected settings match production requirements?