Hi PeerDB team,
It would be very useful to support PostgreSQL mTLS / client certificate authentication for Postgres peers.
Right now PeerDB already has most of the TLS pieces in place: Postgres peers support require_tls, root_ca, and tls_host, and the connector already builds a TLS config for server certificate validation. What seems to be missing is client certificate authentication: sslcert / sslkey or equivalent fields in the peer config, UI, and connector code.
This is especially useful for CloudNativePG users. CNPG makes certificate-based PostgreSQL access a natural security model, and many production setups prefer client certificates over long-lived database passwords.
Why this matters:
- avoids storing static Postgres passwords in PeerDB
- fits Kubernetes-native secret/certificate management
- works well with CloudNativePG-generated client certificates
- improves security posture for CDC connections
- makes PeerDB easier to use in regulated or security-conscious environments
Suggested implementation:
- add optional
client_cert and client_key fields to PostgresConfig
- expose them in the Postgres peer UI
- pass them into the existing TLS config as client certificates
- keep password auth unchanged for existing users
This looks like a relatively small addition because server-side TLS support is already mostly there. It mainly needs a couple of config fields, UI inputs, and wiring client certificates into the Postgres connector.
Thanks!
Hi PeerDB team,
It would be very useful to support PostgreSQL mTLS / client certificate authentication for Postgres peers.
Right now PeerDB already has most of the TLS pieces in place: Postgres peers support
require_tls,root_ca, andtls_host, and the connector already builds a TLS config for server certificate validation. What seems to be missing is client certificate authentication:sslcert/sslkeyor equivalent fields in the peer config, UI, and connector code.This is especially useful for CloudNativePG users. CNPG makes certificate-based PostgreSQL access a natural security model, and many production setups prefer client certificates over long-lived database passwords.
Why this matters:
Suggested implementation:
client_certandclient_keyfields toPostgresConfigThis looks like a relatively small addition because server-side TLS support is already mostly there. It mainly needs a couple of config fields, UI inputs, and wiring client certificates into the Postgres connector.
Thanks!