SSL Key Logging

ProxySQL can write TLS session secrets in the NSS key-log format. Wireshark and tshark can use those secrets to decrypt a matching packet capture, which is useful when diagnosing TLS handshakes or encrypted MySQL and PostgreSQL traffic.

Availability

SSL key logging is available from ProxySQL 2.5.3. One setting covers MySQL and PostgreSQL frontend TLS connections and TLS connections that ProxySQL opens to backends, monitors, and cluster peers. Only new TLS handshakes add key material to the file; existing pooled connections do not.

Security Warning

The key log enables decryption of captured TLS sessions. Protect it like a credential: restrict access, transfer it only over a secure channel, and delete it securely after the investigation.

Enable this feature only for a controlled troubleshooting window. The key log and packet capture together can expose queries, results, credentials, and other application data. Both files also continue consuming disk space while collection runs, so limit the capture duration and monitor the target filesystems.

Configuration

The Admin-interface variable is admin-ssl_keylog_file. An absolute path is used as written; a relative path is resolved below the ProxySQL data directory.

SET admin-ssl_keylog_file = '/var/log/proxysql/sslkeys.log';
LOAD ADMIN VARIABLES TO RUNTIME;

SELECT variable_name, variable_value
FROM global_variables
WHERE variable_name = 'admin-ssl_keylog_file';

To retain the setting across a restart, run SAVE ADMIN VARIABLES TO DISK. In a configuration file, omit the module prefix because the setting is already inside admin_variables:

admin_variables=
{
    ssl_keylog_file="/var/log/proxysql/sslkeys.log"
}

Restart ProxySQL after changing the configuration file.

File Ownership and Rotation

The directory must exist and be writable by the account that runs ProxySQL. Pre-create the file with restrictive ownership and permissions appropriate to that service account, for example:

sudo install -d -o proxysql -g proxysql -m 0700 /var/log/proxysql
sudo touch /var/log/proxysql/sslkeys.log
sudo chown proxysql:proxysql /var/log/proxysql/sslkeys.log
sudo chmod 0600 /var/log/proxysql/sslkeys.log

ProxySQL opens the file in append mode. PROXYSQL FLUSH LOGS closes and reopens it; the command does not truncate or rename the existing file. For manual rotation, move the current file first and then reopen it:

sudo mv /var/log/proxysql/sslkeys.log /var/log/proxysql/sslkeys.log.old
sudo touch /var/log/proxysql/sslkeys.log
sudo chown proxysql:proxysql /var/log/proxysql/sslkeys.log
sudo chmod 0600 /var/log/proxysql/sslkeys.log /var/log/proxysql/sslkeys.log.old
mysql -h 127.0.0.1 -P 6032 -u admin -p -e 'PROXYSQL FLUSH LOGS;'

Confirm that the newly created file retains the intended owner and mode.

Wireshark Usage

Capture only the traffic and duration needed for the diagnosis. This example captures frontend MySQL traffic for 60 seconds:

sudo timeout 60 tcpdump -i any -w /tmp/proxysql-tls.pcap port 6033

Copy the packet capture and key log to a secured analysis system. In Wireshark, open Preferences → Protocols → TLS and set (Pre)-Master-Secret log filename to the key-log path, then open the capture. The equivalent command-line workflow is:

tshark -r /tmp/proxysql-tls.pcap \
  -o tls.keylog_file:/secure/path/sslkeys.log \
  -Y 'tls' -V

Disabling

Close the key-log file as soon as collection is complete:

SET admin-ssl_keylog_file = '';
LOAD ADMIN VARIABLES TO RUNTIME;
SAVE ADMIN VARIABLES TO DISK;

If the value came from the configuration file, remove it there as well before the next restart. Securely remove both the key log and any packet captures after analysis and according to your retention policy.

Troubleshooting