Every time a database client sends a query or receives a result set, that data travels across a network. On a private, isolated network with no external access, this may be an acceptable risk. In most real-world environments, however, where traffic crosses shared infrastructure, cloud networks, or the open internet, an unencrypted database connection is a significant exposure. SSL/TLS encryption closes that gap, and configuring it correctly is one of the more important and frequently overlooked steps in securing a database environment.
Why Unencrypted Connections Are a Real Risk
Without encryption, the data exchanged between a database client and server travels in plain text. Anyone positioned on the same network path - whether through a compromised router, a misconfigured cloud virtual network, or an insider threat - can potentially read that traffic. This includes not just query results, but also authentication credentials. A captured login packet from an unencrypted database connection hands an attacker a valid username and password without requiring any further effort on their part. The risk isn't theoretical; network-level interception is a well-documented attack technique, and its impact is considerably worse when the intercepted traffic comes from a database.
Understanding the Certificate Chain
Transport Layer Security (TLS) is built on a system of digital certificates. Before encrypted communication can begin, the server presents a certificate to the client that proves its identity, effectively saying: "I am who I claim to be, and here is a cryptographically signed document from a trusted authority to prove it." That trusted authority is a Certificate Authority (CA), and its role is to vouch for the identities of the certificates it issues.
In practice, this means you need three things to establish a properly verified TLS connection to a database server:
- The server must have a valid certificate issued by a CA.
- The client must have a copy of the CA's certificate so it can verify the server's identity.
- (optionally) For mutual TLS (mTLS) - the client presents its own certificate to the server as well, so authentication runs in both directions. This optional client-side authentication is sometimes called certificate-based authentication, and it provides a significantly stronger guarantee than password-based authentication alone.
Key Configuration Options to Understand
When configuring TLS for a database connection, several parameters appear consistently across different database systems and clients:
- The CA certificate file is the trust anchor. It tells the client which certificate authority to trust when verifying the server's identity.
- The client certificate file and client key file are used when mutual TLS is required, allowing the server to verify the client's identity in turn.
- The cipher specification controls which encryption algorithms are acceptable for the session; specifying strong, modern ciphers rather than accepting defaults is good practice, since older cipher suites have known weaknesses.
PostgreSQL SSL Options
PostgreSQL adds a particularly useful dimension to this with its SSL mode setting, which lets you define exactly how strict the connection should be. The options range from allow (try without SSL first, fall back to SSL if needed) and prefer (try SSL first, fall back to unencrypted) through require (SSL only, but don't verify the certificate) to verify-ca (SSL and verify the certificate is from a trusted CA) and verify-full (SSL, verified CA, and the server hostname must match the certificate). For production environments, verify-ca or verify-full are the appropriate choices as anything less permissive than require leaves room for a man-in-the-middle attack.
SSH Tunneling as an Alternative Approach
SSL/TLS encrypts the database protocol itself. Secure Shell (SSH) tunneling takes a different approach: it wraps the entire database connection inside an encrypted SSH session. The database client connects to a local port, an SSH tunnel forwards that traffic over an encrypted connection to the remote server, and the database server sees a local connection from the tunnel endpoint. SSH tunneling is particularly useful in situations where the database server does not have TLS configured, or where direct database ports are not exposed externally for firewall reasons, since it requires only SSH access rather than database-level TLS configuration. It's also a straightforward way to secure remote access for administrators who need to connect interactively to a database that sits behind a bastion host.
How Navicat Supports SSL/TLS and SSH Tunneling
Navicat's desktop products - including Navicat Premium and the individual database-specific clients - provide SSL/TLS configuration directly within the connection settings interface, accessible through a dedicated SSL tab when creating or editing a connection. From there, users can enable SSL, supply the CA certificate file needed to verify the server's identity, and optionally provide a client certificate and client key file for mutual TLS. A cipher specification field allows administrators to restrict which cipher suites are acceptable for the connection, rather than relying on negotiated defaults. For PostgreSQL connections specifically, Navicat exposes the full range of SSL mode options described above, giving administrators precise control over how strictly the connection is verified.
SSH tunneling is also supported natively across Navicat's product family. The SSH tab in the connection dialog allows users to configure a tunnel through an intermediate SSH server, with support for both password-based and public/private key pair authentication. This makes it straightforward to connect securely to databases that are not directly exposed to external networks.
Navicat On-Prem Server extends this SSL/TLS support to collaboration as well. Connections between the On-Prem Server and its clients can be encrypted using SSL/TLS, with administrators able to configure the specific cipher suites used for those sessions. SSL/TLS can also be applied to the connection between Navicat On-Prem Server and its underlying repository database, ensuring that the internal plumbing of the collaboration platform is encrypted end to end, not just the connections from end users.
Conclusion
Configuring SSL/TLS for database connections is not a complex undertaking, but it does require attention to the details, such as certificate management, mode selection, cipher configuration, that are easy to get wrong or leave at insecure defaults. The reward for getting it right is a meaningful reduction in the risk that network-level interception will result in credential theft or data exposure. For any database that handles sensitive data or is accessed over anything other than a fully private, isolated network, properly configured TLS is not optional - it is a baseline requirement.
