Skip to content
  • There are no suggestions because the search field is empty.

Enable SSL/TLS for your database connection

Learn how to configure SSL/TLS and use certificates to securely connect your database to Databox.

Availability

profile  Users, Editors, and Admins

box  All accounts

lock  Exclusive to select subscription plans


When connecting your database to Databox (or any external tool), using SSL/TLS encryption ensures that data in transit is secured, prevents eavesdropping or tampering, and verifies the identity of the database server (and optionally the client). This article explains what SSL/TLS means, how it works (keys, certificates, authorities, bundles), what types of connection setups you’ll typically see, and includes commands and links to external provider-documentation so you can create and install the necessary keys/certificates.

What is SSL/TLS and why use it?

“SSL” (Secure Sockets Layer) was the original protocol for encrypting network communications; its successor is “TLS” (Transport Layer Security). In practice people often say “SSL” even when they really mean TLS.
Using SSL/TLS gives you three key benefits:

  • Encryption: The data transmitted between client and server is scrambled so that eavesdroppers cannot read it.
  • Integrity: The data cannot be silently modified without detection.
  • Authentication: You (and optionally the client) can verify that you’re really talking to the server you think you are (and vice-versa).

For database integrations, this means that when Databox connects to your database (for example on Amazon Aurora, Azure SQL, Google BigQuery etc.), using SSL/TLS helps ensure that credentials, queries, and returned data aren’t visible to intermediate network attackers and that the endpoint is trusted. 

How SSL/TLS works

SSL/TLS encrypts the connection between Databox and your database so that data cannot be intercepted or modified while it travels across the network. It also allows Databox to verify that it is connecting to the correct database server.

When an SSL connection is established, the database server sends a certificate that proves its identity. Databox checks that certificate before continuing the connection.

Certificates and certificate authorities

A certificate is a digital document that contains a server’s public key and identifying information, such as its hostname and the organization that issued the certificate.

Certificates are issued by certificate authorities (CAs). A CA signs the certificate to confirm that the server identity is legitimate.

Some databases use self-signed certificates, which are signed by the same entity that created them instead of a public CA, and while not trusted by default, they can be verified by providing the certificate (or its CA) in the CA certificate (ssl-ca) field.

When Databox connects to your database, it checks that:

  • the certificate was issued by a trusted certificate authority (either a public CA or a certificate you provided)
  • the certificate has not expired
  • the certificate matches the hostname of the database server 

If these checks pass, Databox trusts the server and establishes an encrypted connection.

CA certificates and bundles

To verify a server certificate, Databox may need the CA certificate that issued it.

Some providers distribute these as a CA bundle, which contains one or more CA certificates used to verify the server certificate.

You typically provide this certificate or bundle in the CA certificate (ssl-ca) field when configuring the connection.

Client certificates (optional)

Some databases require client authentication, also called mutual TLS (mTLS).

In this case, the database server also verifies the identity of the client (Databox). To do this, you must provide:

  • a client certificate (ssl-cert)
  • a client private key (ssl-key) 

These allow Databox to prove its identity to the database server.

Most cloud databases (such as AWS RDS, Azure, and Google Cloud SQL) do not require client certificates, and only the CA certificate is needed.

Resources

If you need help obtaining SSL certificates for your database, refer to your provider’s documentation:

These guides explain how to download the CA certificate or CA bundle required to verify your database server.

Frequently Asked Questions

Do I always need to supply a client certificate for SSL?

No. Many database deployments use server-only TLS (the server presents a certificate, the client verifies it). Client certificates (mutual TLS) are optional and add an extra layer of authentication.

Does using SSL guarantee database access is completely safe?

SSL greatly improves transport security (encryption/integrity/authentication), but you should still enforce best practices: use strong credentials, limit server access, apply least-privilege permissions, monitor for suspicious activity. SSL is one important layer of defense, not the only one.

What if I use a cloud provider’s database (RDS/Aurora/Azure/Cloud SQL)?

For many cloud‐managed databases you’ll connect using SSL by default or optionally, and the provider will publish the CA certificate bundle that you should use. You still need to configure Databox to use it.

Why do I see “certificate verify failed” or “hostname mismatch”?

This error usually means Databox cannot verify the database server’s SSL certificate.

Check the following:

  • Verify the hostname – Make sure the hostname in your connection settings matches the database endpoint used in the SSL certificate.
  • Confirm the CA certificate – Ensure you pasted the correct CA certificate or CA bundle in the CA certificate (ssl-ca) field. If you’re using a cloud database, download the latest CA bundle from your provider.
  • Check certificate validity – Certificates expire, so confirm the certificate you are using is still valid and has not been rotated by your provider.

Still need help?

Visit our community, send us an email, or start a chat in Databox.