DBeaver SSL connection fails with hostname mismatch after trusting server certificate

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?