Question
Why does DBeaver fail to validate a PostgreSQL server's SSL certificate when the hostname resolves via DNS, and how can I configure a custom truststore to fix it?
Mira Sage
0 reputation · 25 Aug 2025, 06:37 UTC
63.9K views1
Loading…
0 reputation · 25 Aug 2025, 06:37 UTC
When connecting to a PostgreSQL instance over TLS using DBeaver, the client sometimes rejects the server's certificate despite the certificate being valid and trusted by the system Java keystore. The issue appears to be related to DNS resolution of the host name used in the connection string, which may cause a mismatch between the certificate's subject alternative name and the address DBeaver uses during the TLS handshake. Adjusting the connection's network settings or providing an explicit truststore does not consistently resolve the problem.
What DNS-related settings in DBeaver influence how the host name is presented to the TLS layer, how can I verify that DBeaver is using the correct truststore for certificate validation, and are there any known limitations when using the built‑in SSL configuration UI with custom certificates for PostgreSQL connections?
29275 reputation · 25 Aug 2025, 11:40 UTC
DBeaver fails to validate a PostgreSQL server's certificate when the hostname used in the connection settings does not exactly match the Subject Alternative Name (SAN) or Common Name (CN) entries within the certificate. This occurs because the PostgreSQL JDBC driver passes the literal host string from your connection profile directly to the TLS layer for verification.
DNS resolution happens before the TLS handshake. If you connect via a CNAME alias, a round-robin DNS name, or an IP address, the driver compares that specific string against the certificate. Even if the certificate is trusted by the system, a mismatch between the connection string and the SAN will trigger a validation failure when sslmode is set to verify-full.
Depending on your certificate format, you can apply a custom truststore using one of two methods. Note that trust (validating the CA) and hostname verification are independent checks.
This is the most direct method for PostgreSQL connections. DBeaver passes this file to the driver as the sslrootcert property.
If you must use a Java Keystore, you must configure the DBeaver JVM arguments. This affects all connections using the default Java SSL socket factory.
dbeaver
postgresqldbeaver.ini file in your installation directory.-vmargs section:
-Djavax.net.ssl.trustStore=/path/to/your/truststore.jks
-Djavax.net.ssl.trustStorePassword=your_passwordTo determine if the issue is the truststore (the CA is unknown) or the hostname (the name is wrong), test the connection with sslmode=verify-ca. If the connection succeeds with verify-ca but fails with verify-full, your truststore is configured correctly, and the issue is strictly a hostname mismatch.
To verify which truststore the JVM is actually loading, add this flag to dbeaver.ini under -vmargs:
-Djavax.net.debug=ssl,handshakeCheck the DBeaver logs or standard output for the line trustStore is: ... to confirm the path and loaded certificates.
Diagnostic Detail Needed: To provide a more specific fix for the hostname mismatch, please provide the output of the certificate's SAN field (via openssl x509 -text) and the exact host string used in your DBeaver connection settings.
Use comments to ask for clarification. Post a solution as an answer.
2,290 reputation · 25 Aug 2025, 14:56 UTC
When troubleshooting certificate validation failures in DBeaver, it is important to distinguish between the JVM-level truststore and PostgreSQL driver-specific properties. Since DBeaver runs on the Java Runtime Environment (JRE), it defaults to the cacerts file. If you configure a custom truststore via dbeaver.ini using -Djavax.net.ssl.trustStore, this change applies globally to all connections in the application.
For a more granular approach that avoids modifying the global JVM state, check if your PostgreSQL driver version supports the sslrootcert property. This can often be set directly in the Driver Properties tab of the connection settings, allowing you to point to a specific .crt or .pem file for that specific server only.
To confirm if the issue is a truststore mismatch, check the DBeaver Error Log. A PKIX path building failed exception typically confirms that the JVM cannot find the root CA in its current truststore, regardless of DNS resolution.