Connections and Authentication / SSL

ssl

• What it does: Enables or disables SSL/TLS encryption for all client connections.
• Why it matters: SSL encryption is essential for protecting data in transit between clients and the database server. It prevents eavesdropping, man-in-the-middle attacks, and data interception. In today's security landscape, SSL should be considered mandatory for any production environment, especially when transmitting sensitive data over networks.
• Ideal value & Best Practice: Set to on for all production environments. Ensure you have valid certificates configured before enabling. Test both encrypted and unencrypted connection options during migration period, but ultimately require SSL for all production traffic.

ssl_ca_file

• What it does: Specifies the location of the certificate authority (CA) file that contains trusted SSL certificate authorities.
• Why it matters: The CA file enables the server to verify client certificates during mutual SSL authentication. This is crucial for establishing trust in certificate-based authentication scenarios and ensuring only authorized clients can connect.
• Ideal value & Best Practice: Set to the path of your trusted CA bundle (e.g., /etc/ssl/certs/ca-certificates.crt). Keep the file secure with appropriate permissions (readable by postgres user only). Regularly update the CA bundle to maintain trust security.

ssl_cert_file

• What it does: Specifies the location of the SSL server certificate file that the server presents to clients during SSL handshake.
• Why it matters: This certificate authenticates the server to clients, preventing impersonation attacks. A valid, trusted certificate ensures clients are connecting to the genuine database server and not a malicious intermediary.
• Ideal value & Best Practice: Set to your server's SSL certificate file (e.g., /etc/ssl/certs/postgresql.crt). Use certificates from trusted certificate authorities rather than self-signed certificates for production environments. Ensure regular certificate rotation before expiration.

ssl_ciphers

• What it does: Defines the list of SSL cipher suites allowed for encrypted connections.
• Why it matters: Cipher selection directly impacts both security and performance. Strong ciphers provide better security but may require more CPU resources. This parameter allows you to disable weak or vulnerable ciphers while maintaining compatibility with your clients.
• Ideal value & Best Practice: Use modern, secure ciphers such as ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384. Regularly review and update cipher suites to phase out deprecated algorithms. Avoid SSLv3 and weak ciphers like those using CBC mode or RSA key exchange.

ssl_crl_dir

• What it does: Specifies the directory containing certificate revocation list (CRL) files for checking client certificate validity.
• Why it matters: CRL checking ensures that revoked certificates are not accepted, adding an important layer of security for certificate-based authentication. This is particularly important in environments with frequent certificate rotations or security incidents.
• Ideal value & Best Practice: Set to a dedicated directory (e.g., /etc/ssl/crls/) with appropriate permissions. Ensure CRL files are regularly updated and monitor for any performance impact during certificate validation.

ssl_crl_file

• What it does: Specifies the certificate revocation list file used to verify client certificates.
• Why it matters: Provides an alternative to CRL directory for environments that use a single consolidated CRL file. This simplifies CRL management while maintaining the security benefits of certificate revocation checking.
• Ideal value & Best Practice: Use either CRL directory or file based on your PKI infrastructure. Ensure the file is regularly updated and accessible to the PostgreSQL process. Monitor file freshness to prevent valid certificates from being incorrectly rejected.

ssl_dh_params_file

• What it does: Specifies the location of the Diffie-Hellman parameters file for ephemeral key exchange.
• Why it matters: Diffie-Hellman parameters are essential for perfect forward secrecy (PFS), which ensures that session keys cannot be compromised even if the server's private key is later compromised. This is a critical security feature for long-term data protection.
• Ideal value & Best Practice: Generate strong DH parameters (2048-bit or higher) using openssl dhparam -out dhparams.pem 2048 and set the path to this file. Regularly regenerate parameters every 1-2 years as computational capabilities advance.

ssl_ecdh_curve

• What it does: Specifies the elliptic curve to use for ECDH (Elliptic Curve Diffie-Hellman) key exchange.
• Why it matters: ECDH provides stronger security with better performance compared to traditional DH. Curve selection affects both security level and compatibility with various clients and SSL libraries.
• Ideal value & Best Practice: Use prime256v1 (NIST P-256) for broad compatibility or X25519 for modern security. Avoid compromised curves like secp112r1 or secp160r1. Ensure your OpenSSL version supports the selected curve.

ssl_key_file

• What it does: Specifies the location of the SSL server private key file.
• Why it matters: The private key is the most sensitive component of your SSL configuration. Its security is paramount—if compromised, an attacker could impersonate your server or decrypt intercepted traffic.
• Ideal value & Best Practice: Set to your server's private key file (e.g., /etc/ssl/private/postgresql.key). Apply strict file permissions (600) and ensure only the postgres user can read the file. Use passphrase protection initially, but consider using ssl_passphrase_command for automated restarts.

ssl_max_protocol_version

• What it does: Sets the maximum SSL/TLS protocol version the server will use.
• Why it matters: Allows you to restrict protocol versions to prevent use of older, vulnerable protocols. This is important for maintaining security while balancing compatibility with older clients.
• Ideal value & Best Practice: Set to TLSv1.3 for maximum security where supported. For broader compatibility, use TLSv1.2. Avoid TLSv1.0 and TLSv1.1 as they have known vulnerabilities and are deprecated.

ssl_min_protocol_version

• What it does: Sets the minimum SSL/TLS protocol version the server will accept.
• Why it matters: Prevents connections using outdated, insecure protocol versions. This is crucial for eliminating vulnerabilities associated with older SSL/TLS implementations.
• Ideal value & Best Practice: Set to TLSv1.2 as minimum for all production environments. Consider TLSv1.3 for new deployments. Never allow SSLv3 or earlier versions due to critical security vulnerabilities.

ssl_passphrase_command

• What it does: Specifies a command to retrieve the passphrase for decrypting the SSL private key file.
• Why it matters: Allows automated server restarts without manual passphrase entry while maintaining key encryption. This is essential for operational efficiency while preserving security through encrypted private key storage.
• Ideal value & Best Practice: Use a secure mechanism such as a dedicated secrets management tool or encrypted configuration store. Ensure the command itself is secured and doesn't expose the passphrase in process listings or logs.

ssl_passphrase_command_supports_reload

• What it does: Controls whether the passphrase command is called during configuration reload (SIGHUP).
• Why it matters: Determines if SSL certificates can be reloaded without restarting the database server. This affects operational procedures for certificate rotation and maintenance.
• Ideal value & Best Practice: Set to on if your passphrase command can safely be called during reload operations. This enables certificate rotation without service interruption, improving availability and security posture.

ssl_prefer_server_ciphers

• What it does: Gives priority to the server's cipher preference order rather than the client's.
• Why it matters: Ensures that stronger, more secure ciphers are selected even if clients prefer weaker options. This is important for maintaining consistent security standards across all connections.
• Ideal value & Best Practice: Set to on for all environments. This ensures that your carefully curated cipher list is respected, preventing clients from negotiating weaker ciphers than your security policy allows.

---

Try pghealth Free Today 🚀

Start your journey toward a healthier PostgreSQL with pghealth.
You can explore all features immediately with a free trial — no installation required.

👉 Start Free Trial