Unexpected Rethrowing when testing Database connection

Products

• CA Automic Workload Automation - Automation Engine
• CA Automic One Automation

Issue/Introduction

When using the Test button in the Connection Test section of a database connection object (CONN.SQL) that connects to a SQL Server database, an error shows up:

U02012064 The driver could not establish a secure connection to SQL Server by using Secure Sockets Layer (SSL) encryption. Error: 'Unexpected rethrowing'.

The database is an older database (like SQL Server 2014) which does not allow higher security standards like TLS 1.2.

The jdbc driver being used is 9.2.0 and java is a newer version (latest 1.8 or any 11.0 openjdk)

This usually happens after an upgrade of the Automic agent, jdbc driver, or java version.

Environment

Automic: 21.0 or higher
Database the agent is connecting to: Older SQL Server
java used by DB_Service agent: openjdk 11.0

Cause

This is caused by older versions of SQL Server using an older encryption (SSL/TLS) standard than what is required or used by the jdbc driver

Resolution

Due to the higher security standards being required by one side or the other (TLSv1.2 or TLSv1.3 required by jdbc for example) and the lower security standards being used by the other side (TLSv1 or TLSv1.1 required by the database server for example), a generic jdbc driver may be needed.  One example could be jtds (https://sourceforge.net/projects/jtds).  Once you've downloaded a driver:

• Stop the DB_SERVICE agent
• Put the jdbc driver into the DB_SERVICE agent /bin/jdbc directory
• Start the DB_SERVICE agent
• Open the connection object and choose "Generic JDBC" from the Database Type drop-down
  
• Update the Connection string to the connection string required by the jdbc provider.  For example, a jtds connection string might be: jdbc:jtds:sqlserver://[SQL Server server DNS]:[SQL Server port]/[database name]
• Test the connection again

Remember to discuss any changes like this with security and system admins before using them.

To fully resolve the issue without using a generic jdbc driver, the latest version of a compatible database, drivers, and java should be used so that a workaround is not needed.

Additional Information

You may be able to find more information about what security protocol is being used by starting the agent from the command line and using the following start flag:

-Djavax.net.debug=ssl:handshake:verbose

For example, if the agent usually starts with a command:

java -jar ucxjsqlx.jar

then starting it with:

java -Djavax.net.debug=ssl:handshake:verbose -jar ucxjsqlx.jar

will add additional output to the standard out.  You may see something like this:

"ClientHello": {
  "client version"      : "TLSv1.2",
...
    "server_name (0)": {
      type=host_name (0), value=databaseserver.example.org
    },
...
    "supported_versions (43)": {
      "versions": [TLSv1.3, TLSv1.2]
    },

In that case above, the SQL Server the test is being run against is databaseserver.example.org and the versions of TLS being used by the client (required by the jdbc driver) are TLSv1.2 or TLSv1.3.