Connection Fails in External Database Syncroniser
Symptom
When you save or test a connection to an external database, the connection fails immediately. The error refers to the SSL or TLS certificate, to a failed handshake, or to a certification path that could not be built.
Cause
The app encrypts every connection to an external database using TLS. Before sending any data, it checks the certificate presented by your database server to confirm the server is genuinely the one you configured, and not another machine on the network path answering in its place.
That check fails when the certificate cannot be traced back to a certificate authority the app trusts. In practice this is nearly always one of the following:
What is on your database server | Why the check fails |
|---|---|
A self-signed certificate | The most common cause. SQL Server, MySQL and most other engines generate a self-signed certificate on installation if none is supplied. It is signed by the server itself, so there is no authority to verify it against. |
A certificate issued by an internal certificate authority | The certificate is legitimate within your organisation, but the app runs on infrastructure that has no knowledge of your internal certificate authority. |
A valid certificate, wrong hostname | The hostname in the connection configuration does not match the common name or any subject alternative name on the certificate. |
An expired certificate | The certificate was valid and is no longer. Connections that worked for months stop working overnight. |
This is expected behaviour
The connection is being refused by design. Encryption alone is not sufficient: without a verifiable certificate there is no way to confirm which server is receiving your data. The app does not send data to a server it cannot identify.
Why the same connection worked on Data Center
The two hosting models place the app in different positions relative to your database.
On Data Center, the app runs inside your own infrastructure and connects to your database across your own network, using the trust settings of the environment your administrators maintain. Certificates issued by your internal certificate authority are typically already trusted there.
On Cloud, the app runs on the vendor's infrastructure. The connection originates outside your network and travels to reach your database. The infrastructure is different, more parties are involved, and the security controls applied to the connection differ accordingly. A certificate that was accepted in one environment is therefore not necessarily accepted in the other.
Resolution
Install a certificate on your database server that is issued by a publicly trusted certificate authority, then confirm the connection details match it.
Obtain a certificate for your database server from a publicly trusted certificate authority.
Include the correct hostname. The hostname you enter in the app must appear on the certificate as the common name or as a subject alternative name. If you connect by IP address, the certificate must list that IP address.
Install the certificate on the database server and restart the database service. Consult your database vendor's documentation for the exact procedure.
Test the connection in the app.
Plan for renewal
Certificates expire. Track the expiry date of the certificate you install and renew it ahead of time. An expired certificate will cause this connection to fail again, without warning, on the day it lapses.
If your database uses an internal certificate authority
Contact support before making any changes. Your certificate may already be correctly configured for your organisation, and the appropriate resolution is likely to be different from the steps above.
Still unable to connect
Raise a support request and include:
The database engine and version
The hostname or IP address you are connecting to
The full error message shown by the app
Whether the certificate on the database server is self-signed, issued by an internal certificate authority, or issued by a public certificate authority
Whether this connection previously worked, and on which hosting model