PostgreSQL TLS configuration reference

TLS (Transport Layer Security) provides a secure communication channel between Kong Gateway and PostgreSQL. When configured correctly, TLS ensures encrypted traffic, verifies authenticity, and helps maintain data integrity.

Mutual TLS (mTLS) enhances this by requiring both the client Kong Gateway and the PostgreSQL server to authenticate each other. This approach further reduces the risk of unauthorized access by validating the identities at both ends of the connection.

Using TLS and mTLS for database communication introduces benefits such as:

• Encryption: Protects data in transit from being intercepted.
• Authentication: Verifies both the server and client identities.
• Integrity: Prevents tampering during transmission.

However, enabling TLS or mTLS does add operational complexity. Proper configuration requires valid certificates, matching protocol versions, and secure file permissions.

Kong Gateway supports TLS and mTLS when connecting to PostgreSQL and provides configuration options to control verification depth, trusted certificate authorities, and client certificate authentication.

PostgreSQL must be compiled or installed with TLS support. In mTLS setups, the server must also validate client certificates, typically by matching certificate metadata with database access rules.

Certificates can be generated with OpenSSL. The most secure setups use an intermediate CA chain.

Self-signed certificates can be used for testing but are not recommended for production.

Intermediate Certificate Chain

In a secure TLS setup, certificate authorities may include an intermediate CA between the root CA and the server or client certificate. This chain strengthens trust and is a common production setup.

To configure:

• Generate a root CA certificate to serve as the ultimate trust anchor.
• Issue an intermediate certificate signed by the root CA.
• Use the intermediate CA to sign server and client certificates.
• Assemble the certificate chain by appending the intermediate and root certificates in order.
• Ensure PostgreSQL and Kong Gateway are configured to trust the appropriate CA certificates.

This approach enhances security by keeping the root CA offline and delegating trust to intermediates.

Root-Only Certificate Chain

In this simpler setup, the root CA directly signs both server and client certificates. This reduces complexity but can increase risk.

To configure:

• Generate a root CA certificate and private key.
• Use the root CA to sign the server and client certificates.
• Trust is established by distributing the root CA certificate to both PostgreSQL and Kong Gateway.

This setup is easier but lacks the layered security of intermediate chains.

Self-Signed Certificates

Self-signed certificates are useful for local testing or development, but should not be used in production.

To configure:

• Generate a self-signed server certificate and private key.
• Generate a self-signed client certificate and private key.
• Configure PostgreSQL and Kong Gateway to trust these certificates directly.

Self-signed certificates do not chain to a CA, so each system must explicitly trust the individual certs.