Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uqsAe-00EQeK-Jj for pgsql-general@arkaria.postgresql.org; Tue, 26 Aug 2025 11:49:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uqsAe-005Hvr-2m for pgsql-general@arkaria.postgresql.org; Tue, 26 Aug 2025 11:49:00 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uqsAd-005HtI-OK for pgsql-general@lists.postgresql.org; Tue, 26 Aug 2025 11:49:00 +0000 Received: from mail-yw1-x1143.google.com ([2607:f8b0:4864:20::1143]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uqsAc-001weG-00 for pgsql-general@lists.postgresql.org; Tue, 26 Aug 2025 11:48:59 +0000 Received: by mail-yw1-x1143.google.com with SMTP id 00721157ae682-71d603f13abso47812197b3.0 for ; Tue, 26 Aug 2025 04:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756208936; x=1756813736; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=3MQjMUgqHjhX8Zgdmee1lt1E1V4r8UPlqkT0CKyqUes=; b=Nq3Ac8WWFrHxNnOywZKxFCVteYu2blpUBUu0wOzIVL4T3axzzbkC7HUxpnJybMUIDo I61ymCsIlNg07Gp6MX5jkYT9ZbcMKMF0MzMqNficzoSk0WT3juGxBRdtbW59Qbg/Dqg6 GbC87xG4vwyNPC+Tq3NtxUvmy2b6YwkQZ5sGkzFJ5C2lLbXeihrCeCgHWq8+JVsShDxQ bn7BNWoxaLYOkpzHlVH01rzWLqO057QZTXrYZC2pWD9CzhRPmcacG8eS76K39dA9ll58 6RsmaEzpc99YhBlITIs9t7YyVQtG9nmF20D9OQNFebesD7I7OpRBW3h6FdX1cKlo5grP xM6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756208936; x=1756813736; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=3MQjMUgqHjhX8Zgdmee1lt1E1V4r8UPlqkT0CKyqUes=; b=N40xL8mk3PPka8ut8d7gty6sBKkdBw8GydqCNXrkIkCv1dDjg9RSjiiOlQ55G9r7nt m9FFll1i+ve7e27sIlgXHNL26Rw7GqcKfjd5SBMSfqPHq1yJZ45vRcZvxaGslisM8LvV gr6paY/vdJIaAGd6hMbDBnw63REgHJ2xigKrKyYY/IJfVsE0FSKXJXzt0t1FKqVd7Quw EYXtE4n/XgMmAr3wz8GsyQkonimTnk2tW5O62y484Z9bjz7shINjceS6vjQ1nXY/2hoX s1ns+8bDWW8WGePydlI27upgjFnIyU5mPRfHEW85fYiDj23LscIyeiPzpa4F+xrDo+TU Df7Q== X-Gm-Message-State: AOJu0Ywh7DH8lUUzbORmwY1rE8DSy273daLTX26H1w64IAoNu/goWVNe K3pmAS3awlgabRj1iXyUnAXrNNvgBsu9X2n1nTXRFy3j+2JphZ1Gc6H1QV5/SGYTkXvb7Ey2vFS SWnSYQHXLhn4CfmCsGXDJcQfL+9mjG9/ovu1dmF5RwA== X-Gm-Gg: ASbGncuIIrUBOKXTPBUMUDVOJVo6a4hJyax15axs+tsmbD2gv/aV1qDUvwAnCfealfB yP9ZlT1sXr60KHSS+KYIt75jC/XP0waOxZ9/ZucuJJhyGOXunuWK7twjk0Ue44NueMSU1RfS6tN ty/1A39cegA8Xha4M0zxEJJn/LKScX9dq7xh992QeL2UiNYkx4outh1XWZo9kvdpnk0WSvZD0Ju orCofB7 X-Google-Smtp-Source: AGHT+IG1huYdPktqjcvDLgWec/SKO5QkoZbFtkS279i7b9uU4wIGzmI/F1FHxi8EwF4/MvLIO3+sjUXcJWaiSKrVy0Y= X-Received: by 2002:a05:690c:b06:b0:71f:b944:100e with SMTP id 00721157ae682-71fdc574e0dmr184659237b3.53.1756208935910; Tue, 26 Aug 2025 04:48:55 -0700 (PDT) MIME-Version: 1.0 From: xx Z Date: Tue, 26 Aug 2025 19:48:44 +0800 X-Gm-Features: Ac12FXwyD54n1vPOczvpI5Tuhzfqsc5lEzohb5ZRqIKG9SC0M6qtyK2ZSLYv0TE Message-ID: Subject: How to configure client-side TLS ciphers for streaming replication? To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="000000000000c6bea3063d43414b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000c6bea3063d43414b Content-Type: text/plain; charset="UTF-8" Hello, Is there a way for a streaming replication standby (client) to restrict its list of supported TLS ciphers, similar to how the ssl_ciphers parameter works on the primary server? We need this for security compliance but can't find an equivalent setting for the client-side connection in primary_conninfo. Thanks, --000000000000c6bea3063d43414b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello,
Is there a way for a streaming replication standby = (client) to restrict its list of supported TLS ciphers, similar to how the = ssl_ciphers parameter works on the primary server?
W= e need this for security compliance but can't find an equivalent settin= g for the client-side connection in primary_conninfo.
Thanks,
--000000000000c6bea3063d43414b--