Skip to content
The latest version of DbVisualizer was released 2024-07-04DOWNLOAD HERE ->


When DbVisualizer communicates with a database server, all communication (except passwords) is done in plain text; by intercepting the communication, someone can access the transmitted data and even modify it while in transit. To protect your communication you need to encrypt the communication between DbVisualizer and the server. Kerberos, LDAP, Radius, security mechanisms, external authentication options, SSH server forwarding, and a lot of other database specific features are not directly related to DbVisualizer, but we will do our best to assist in these scenarios.

You find additional information on security related to specific databases in our support portal.


Depending on the database and the JDBC driver, you may be able to use SSL (Secure Socket Layer) to encrypt client/server communications and securely authenticate client and server.

In case the JDBC driver supports SSL, you usually define the SSL settings as Driver Properties for your connection according to the documentation for the JDBC driver. The exact details depend on the versions of the database and the driver, but using PostgreSQL as an example, the settings can look like this:

SSL settings in DbVisualizer


For ensuring security of the data being transferred between a client and server, SSL can be implemented either one-way or two-way (aka mutual authentication). In one way SSL, only client validates the server to ensure that it receives data from the intended server. In case of two-way SSL, both client and server authenticate each other to ensure that both parties involved in the communication are trusted.

Trusting the server – One way authentication

A server certificate that is signed by a trusted Certificate Authority (CA) should always work fine, since the Java distribution includes a truststore with all the CA public keys.

When a self-signed server certificate is used, some additional configuration is needed. Depending on the actual JDBC driver this may include importing certificates to a truststore using the Java keytool. Some drivers allow this truststore to be configured per connection instead of for the whole Java VM. When using a truststore that affects the whole JVM special considerations must be taken.

Using a truststore for the whole Java VM

Many forums on the net suggests using the Java keytool to import the certificate into the Java VM's default truststore. The drawback with that solution is that it does not survive a Java upgrade; when the Java VM bundled with DbVisualizer is used, upgrading DbVisualizer effectively causes SSL connections to fail. We therefore recommend creating a truststore separate from the Java VM (e.g. in /Users/me/MyTrustStore) and import the certificate to that Trust Store.

Note that setting the truststore on Java VM level may affect other functionality of DbVisualizer as well as other database connections. E.g. if the certificate of cannot be verified neither Help->Contact Support nor Help->Check for Update will work.

When creating the truststore you should always start with a trust store containing the needed certificates (E.g. the default java Trust Store) and add/import your custom certificate to it.

Do the following:

  1. Copy the Java default truststore to your location (e.g. /Users/me/MyTrustStore). The location of the Java default truststore is in most cases <Java Home>/lib/security/cacerts
  2. Import your server certificate to the truststore using keytool. The password of the Java VM truststore is in most cases changeit. Following is an example of using the keytool when importing a certificate.
keytool -importcert -alias mycert -file ca.pem -keystore /Users/me/MyTrustStore -storepass changeit

(Replace the paths in the samples accordingly.)

The next step is to associate the custom truststore with Java. This is done in Tools->Tool Properties and in the General category. The following Java properties should be added in Specify overridden Java VM Propertieshere input field.

Mutual authentication – two way authentication

Some database servers can be configured to require clients connecting to authenticate using a certificate.

The configuration on the client side (DbVisualizer) resembles the way a truststore is configured. In this case you may create a keystore containing a single certificate. DbVisualizer functionality is not depending on any keys in the JVM keystore.

The next step is to associate the custom keystore with Java. This is done in Tools->Tool Properties and in the General category. The following Java properties should be added in Specify overridden Java VM Propertieshere input field.
Again, there may be drivers supporting configuration of keystores (and truststores) per connection. If this is supported this is the preferred way of configuration.


For an example on how such a certificate can be created, see description below. Note that this and the following commands are just examples and should only be seen as a guideline.

Create your local keystore directory, for example as /users/me/MyKeyStore. Go to this directory and create your keystore and key pair with a command like below:

keytool -genkey -alias dbvisuser -keyalg RSA -validity 365 -keystore client.keystore -storetype pkcs12
Give a password to be used for the keystore and answer the questions. As a result you will finally have the keystore in a created file with name as given: client.keystore

You can now view your keystore with command:

keytool -list -v -keystore client.keystore
And, you can create a certificate (in the example given the name mydomain.crt) to be used by a database server with command:

keytool -export -alias dbvisuser -file mydomain.crt -keystore client.keystore
This new certificate file can then be given to the DBA(s) for the database that you connect to.

Verbose debugging output

If you run into problems and need more verbose logging (displayed in Tools->Debug Window), add this property: