You are asked to make a production database refuse every unencrypted client connection. How do you get there without an outage, and what keeps it working afterwards?

## Why this is a migration Enforcement is a one-line change that fails closed: the moment the server rejects plaintext, every client that has not been migrated stops working, including the ones nobody remembered. The engineering work is in discovering and moving those clients, not in the flag. ## Step 1 -- measure what exists Every mainstream engine exposes, per active connection, whether the session is encrypted, along with the user and client address. Snapshot it repeatedly (not once -- batch jobs connect on schedules) and cross-reference the connection log. Build a list of client -> encrypted? -> owner. The usual surprises: - read replicas and the replication stream itself - backup, dump and restore tooling - schema-migration runners in CI - analytics/BI tools with their own connection settings - monitoring agents and health checks that connect frequently - humans with local clients and old connection strings ## Step 2 -- enable before enforcing Install the server key and certificate, keyed to the hostname clients actually dial, and leave the server accepting both. Nothing breaks; clients can now opt in. If a pooler fronts the database, it needs its own certificate *and* its own verified connection to the database -- two hops, two configurations. ## Step 3 -- migrate clients to verified TLS For each client, set the strongest verification mode and ship the CA bundle as part of the deployment artifact or secret mount. Going straight to full verification is preferable to a two-step 'encrypt now, verify later', because the second step never gets prioritised. Expect hostname mismatches where connection strings use IPs or internal aliases; the fix is the connection string, not a weaker mode. ## Step 4 -- flip enforcement on evidence Add a monitor that counts unencrypted sessions and alerts on any. When it has read zero across a full weekly cycle (so monthly jobs are the only residual risk -- check those explicitly), change the server's connection rules to reject non-TLS connections. Do it in a window with a tested rollback, and prefer to enforce per user/host first if the rule system allows, so a single stubborn client cannot force a full revert. ## Step 5 -- keep it working Enforced, verified TLS turns certificate lifecycle into an availability dependency: - **Automate renewal** and alert on approaching expiry with enough lead time for a human to act -- typically multiple weeks, and always more than one on-call rotation. - **Order CA rotations correctly**: distribute and trust the new CA on all clients *first*, then switch the server's certificate, then retire the old CA. Doing it in the other order is a self-inflicted outage. - **Cover replicas and tooling** in the same rotation, since they are the ones that silently break. - **Monitor the property, not the config.** Keep the 'unencrypted sessions' alert forever; a new service with a copy-pasted connection string will otherwise reintroduce plaintext quietly. - **Document the failure signatures** (expired certificate, untrusted issuer, hostname mismatch, clock skew) so an incident does not start with guesswork. ## A note on cost Symmetric encryption on modern CPUs is negligible; what costs is the handshake, which matters only for workloads that open connections constantly. That is an argument for connection pooling and session reuse rather than an argument against enforcement -- and it is the honest answer if an interviewer pushes on performance.