# Enable SSL/TLS for your database connection 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: - [Amazon Web Services (Aurora / RDS)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.SSL.html) - [Microsoft Azure databases (Azure SQL, Azure MySQL, Azure PostgreSQL)](https://learn.microsoft.com/azure/mysql/howto-configure-ssl) - [Google Cloud SQL (MySQL, PostgreSQL, SQL Server)](https://cloud.google.com/sql/docs/mysql/configure-ssl-instance) These guides explain how to download the **CA certificate or CA bundle** required to verify your database server. 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. 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. 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. 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.   Ask Genie Get instant answers or help with your data using the in-app AI assistant. Talk to an expert For customers: Get help with your setup, strategy, or making the most of Databox. Book a demo New to Databox? See how it works and get guidance on getting started. Send an email Reach out to support for help with your account, data, or technical issues.