Question
DBeaver SSL connection fails with hostname mismatch after trusting server certificate
Ari Sage
0 reputation · 04 Jun 2021, 07:33 UTC
89.1K views
Loading…
0 reputation · 04 Jun 2021, 07:33 UTC
When configuring a DBeaver connection to use SSL with a self‑signed or private‑CA certificate, the user can enable the “Trust server certificate” option or import the certificate into the connection‑specific truststore. The intended goal is to allow the connection to succeed despite the certificate not being present in the Java default truststore. However, it remains unclear whether enabling this option also disables hostname verification, or if DBeaver continues to validate the host name against the certificate’s Common Name or SAN using the system truststore. This uncertainty leads to situations where the connection still fails with a hostname mismatch error even after the certificate has been trusted.
What is the exact effect of the “Trust server certificate” toggle on hostname verification? Does DBeaver use the connection‑specific truststore for both chain validation and host name checks, or does it fall back to the Java cacerts for the SAN/CN comparison? Is there a documented way to force DBeaver to rely solely on the connection‑level truststore for both certificate path and hostname validation?
35275 reputation · 04 Jun 2021, 08:59 UTC
The "Trust server certificate" toggle in DBeaver primarily affects the certificate chain validation, not the identity verification. Enabling this option tells the client to accept the server's certificate as authentic even if it is not signed by a trusted Certificate Authority (CA) in the Java truststore. It does not disable hostname verification.
Hostname verification is a separate security check that ensures the server you are connecting to is actually the server named in the certificate's Common Name (CN) or Subject Alternative Name (SAN). If the hostname in your connection settings does not match the certificate, the connection will fail with a hostname mismatch error, regardless of whether the certificate is trusted.
DBeaver relies on the underlying JDBC driver for SSL implementation. In most driver configurations, the process follows this logic:
DBeaver does not fall back to cacerts for the SAN/CN comparison; it compares the connection string's host address against the certificate provided by the server during the TLS handshake.
To bypass the hostname mismatch while keeping the certificate trusted, you must instruct the JDBC driver to disable strict hostname verification. Because these settings are driver-specific, you must apply them in the Driver properties tab of your connection settings.
| Database | Property / Setting | Value for Bypass |
|---|---|---|
| PostgreSQL | sslmode |
verify-ca (instead of verify-full) |
| MySQL | allowPublicKeyRetrieval / useSSL |
Check driver-specific verifyServerCertificate flags |
| SQL Server | trustServerCertificate |
true |
dbeaversslmode for Postgres).verify-ca).Security Warning: Disabling hostname verification makes the connection susceptible to Man-in-the-Middle (MitM) attacks. This should only be used in development or isolated private networks.
Diagnostic Note: To provide the exact property name for your setup, please specify which database engine and driver version you are using.
Use comments to ask for clarification. Post a solution as an answer.
35,275 reputation · 04 Jun 2021, 13:51 UTC
To build on the previous answer, it is important to note that the Driver properties tab often overrides or supplements the GUI SSL toggles. Because DBeaver is a wrapper for various JDBC drivers, the specific property to disable hostname verification varies by database vendor.
sslmode property is key. Setting this to verify-ca trusts the CA but skips hostname verification, whereas verify-full enforces both.allowPublicKeyRetrieval or specific SSL verification properties depending on the connector version.To verify if a hostname mismatch is the culprit, try connecting via the IP address listed in the certificate's Subject Alternative Name (SAN) instead of the DNS name. If the connection succeeds, it confirms that the certificate is trusted but the hostname identity check is failing. Note that disabling this check exposes the connection to Man-in-the-Middle (MitM) attacks.