Encrypting Every Database Connection on PaaS: What the MySQL, PostgreSQL and Redis TLS Add-Ons Do, and How Applications Follow

Encryption in transit between an application and its database is the control that every security framework asks for and most teams defer, because the traffic stays on an internal network and the certificates are a chore. The marketplace's three TLS add-ons remove the chore: they generate the certificates, configure the server and hand you the client files. This post follows a security engineer closing an audit finding with them on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic.

The company is a health-tech vendor we will call Meadowbrook Health, with nine databases across MariaDB clusters, PostgreSQL clusters and Redis. The MySQL SSL/TLS, PostgreSQL SSL/TLS and Redis SSL/TLS add-ons each attach to a database layer, generate a certificate authority and certificates, configure the engine to encrypt connections and provide client files.

Why encrypt traffic that never leaves the data centre

The internal network between an application node and its database node is not the public internet, and the engineer says so in the risk assessment. The finding stands anyway, for three reasons. Frameworks such as ISO 27001 and the health sector's rules ask for encryption in transit for personal data without exempting private networks. A compromised application node with a packet capture would otherwise read every query. And the multi-region clusters replicate between data centres, where the traffic does cross a wider network. The cost of closing the finding is a few percent of CPU on the database nodes and a slightly longer connection handshake, which connection pooling makes irrelevant.

What the three add-ons have in common

Each installs from the database layer's Add-Ons section (or from the marketplace) onto the selected layer and node groups. Each generates a certificate authority and server and client certificates with a bundled utility, storing them in the platform's keys folder (/var/lib/jelastic/keys/SSL-TLS, reachable via the keys shortcut in the file manager), with server and client subfolders. Each configures the engine, restarts or reloads it gracefully, and each supports scaling: nodes added to the layer later receive certificates and configuration automatically. The certificates are self-signed by the generated CA and issued for each node's hostname, so clients verify against the CA file and, where they check hostnames, must use the node's hostname rather than an IP.

MariaDB clusters and ProxySQL

Meadowbrook's five MariaDB databases are clusters with a ProxySQL entry point, so there are two hops to encrypt: application to ProxySQL and ProxySQL to the database nodes. The MySQL add-on's client bundle is what ProxySQL uses to connect to the nodes, and the engineer configures ProxySQL's own TLS for the front-end connection so the application's connector talks TLS to the proxy. Applications then need one change: enable TLS in the connection string and, for full verification, point at the CA certificate. Three of the five applications were PHP with PDO; adding the SSL CA option to the PDO constructor and redeploying sequentially took the afternoon.

PostgreSQL, and the password reset nobody expects

The PostgreSQL add-on does one thing beyond certificates that surprised the team: it moves password authentication from MD5 to SCRAM-SHA-256, both because it is the better practice and because SCRAM is what makes SSL work through Pgpool-II. Because the hash algorithm changes, existing database users' passwords are reset as part of the installation, and the engineer scheduled the install for a maintenance window and rotated the application secrets in the layer's environment variables at the same time. For the clusters with Pgpool-II, both the PostgreSQL and Pgpool layers are selected at install, as the add-on requires. Applications set sslmode=verify-ca and the CA path; the two Django services needed only their database settings dictionary updated. For the multi-region PostgreSQL cluster, the add-on also configures standbys to connect to the primary over SSL, which is where inter-region replication traffic is encrypted.

Redis, and the port that stays open

The Redis add-on opens a TLS listener on 6380 and leaves 6379 accepting plain connections for backward compatibility. The engineer treats that as a migration window, not a permanent state: clients are moved to 6380 with the CA file, verified with the bundled redli tool, and then the plain port is disabled in settings and closed in the container firewall. For the Redis Cluster the add-on also encrypts the cluster bus between nodes. Because each node has its own certificate for its own hostname, cluster-aware clients must be configured with hostnames rather than IPs, which was the one client change that took debugging.

Closing the finding

The evidence pack for the auditor was short: the add-ons' installation records per layer, a SHOW STATUS LIKE 'Ssl_cipher' from each MariaDB session, pg_stat_ssl output from each PostgreSQL, a Redis INFO showing TLS connections, and the firewall rules closing the plain ports. Nine databases, three add-ons, one afternoon of client configuration and one maintenance window for the PostgreSQL password change. The engineer's note for the next audit: rotate the generated CA before its validity period ends, which the add-ons set to a sensible term, and re-run the client distribution when you do.

Frequently Asked Questions

Can I use my own certificates instead of the generated ones?

Yes. Replace the generated files in the certificate folder with certificates from your own CA, keeping the file names the server configuration expects, and restart the nodes. Distribute your CA to the clients instead of the generated one.

Why not Let's Encrypt for the databases?

Let's Encrypt issues for public hostnames and expires every 90 days, which is awkward for internal database nodes and their clients. The generated internal CA has a long validity, needs no public DNS, and the clients trust exactly one CA you control.

Does TLS change the performance numbers in this blog's other posts?

Marginally. Encryption costs a few percent of CPU on the database node and lengthens the initial handshake; with connection pooling, which the PostgreSQL clusters' Pgpool-II and most application frameworks provide, the steady-state difference is negligible.