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 1uA3BM-009qCD-3N for pgsql-general@arkaria.postgresql.org; Wed, 30 Apr 2025 08:52:44 +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 1uA3BJ-00CZ98-4f for pgsql-general@arkaria.postgresql.org; Wed, 30 Apr 2025 08:52:42 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u9iRX-006LS0-1E for pgsql-general@lists.postgresql.org; Tue, 29 Apr 2025 10:44:04 +0000 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1u9iRW-000AAt-0x for pgsql-general@postgresql.org; Tue, 29 Apr 2025 10:44:03 +0000 Received: by mail-pj1-x1029.google.com with SMTP id 98e67ed59e1d1-309f3bf23b8so6378172a91.3 for ; Tue, 29 Apr 2025 03:44:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1745923441; x=1746528241; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=lRG16DY2y2hdUtwXX+smfAtSd5kQwEZb8QfuohW1uaI=; b=VI7imcsZCeQDZPUKBEiXX5b03EQl4n0nP67BhXM+Utx4X7tLUbn0tnYYr3eTOi+qu/ 9zDWEYcOcj5Y0CbyQR+1i0FhR8ymPboN47srcyaSZ3VTwJfEsk7jInNS3+GJSx5Z1CTm jopKZ+eqT6dRhMLqL5ABr+H7AGxqAFy7vr8tqx3bzCJVV+ghID3RIqztCjcb6EKarUEs vRWnlMMcIjHyUT9lq+G3gtmYdjuEaqb8q98tTMQUF71fVsxg1K/L9cmhaHo/dTF7GgZl GtRJwWJT9y9tznu7NUss2sepZvn6DJrKbvJAOq+l9M8RBYaIXObz/sEZ1zYJYc8GXFeC 2fVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745923441; x=1746528241; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=lRG16DY2y2hdUtwXX+smfAtSd5kQwEZb8QfuohW1uaI=; b=DyUSniffrFdxoOWtzQQMQzrD+GoEtIpoPytfPmYcKVjeme63QCkKwjOxujF+9UTJJY V5AMykxGnCO1lFzdECNujq3CeUAbbpLyZwEdFfLsloiSj7iePzDuOvvTYWY2c6uWN0Ii hMEy9jc9kh/Us53KQPfgZ6rChde7YutCjUHbceSSNiajap9h5b04yOsB+lVowH6YunE0 qJu1hE2VfQ74w3FlD2U1z3lcAqIpe0lVh2EBEtAdMJJxeGrShsRrm7lmAAwaO0sN5Esw TpZb9QW5TBFvfrgMIWCOg0xrKisXsVgpYE3+DmU4kj5fZ90/u5sSWS5hlremgroVNoGO 1YOA== X-Gm-Message-State: AOJu0YxZv0waUMbdk7RWIkwZ0Sy6A6hPNLZdRNdxORzbYq7Fyarrj3IA Y/XrRrMd2SM0a8sO1QCJTSRu4RkhROgpGR55jrESGI5viyJf+bE9MBk4zBObWhrKueFM0pBI9l1 knf/G2E34NPtip2N/O2r3XULl1V3cbNHZ X-Gm-Gg: ASbGnct//5tcSiv3ZrzsXPQzjMaLqnKNxkMiirAi5uRKDVDt7UQF0sYT7utziuYO78h GaA6JAQjNESWlj759QWKVAbe6v/xctHBjFRjF8zUYRmv7FeCeI8K9W5nQBr52lm6Ig27plTCb0f KeWZHwGBX1o8dRzPxSDSibr6s= X-Google-Smtp-Source: AGHT+IEuou+xEz+GuY/xXFQxi3aHNgY76TBAF8eq6wj8L7w4Q9WNdoK2tYacVP4sd/Jl9PPpaHMqz5lDLQNZxUwCN30= X-Received: by 2002:a17:90b:2dc9:b0:2ff:52e1:c49f with SMTP id 98e67ed59e1d1-30a013b1753mr13429785a91.26.1745923441353; Tue, 29 Apr 2025 03:44:01 -0700 (PDT) MIME-Version: 1.0 From: Duygu Hasan Date: Tue, 29 Apr 2025 13:43:49 +0300 X-Gm-Features: ATxdqUFkjbDpjby7ptMhPEV3t5lvDaZXQiyu0d0PGFYZ1jKNoCM9ddzJBUmhJ60 Message-ID: Subject: Pg client certificate auth To: pgsql-general@postgresql.org Content-Type: multipart/alternative; boundary="00000000000086e9140633e87a29" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --00000000000086e9140633e87a29 Content-Type: text/plain; charset="UTF-8" Hello, I am trying to deploy a PG db with client certificate auth. I have read the documentation, but I have a few questions. One of my goals is to be able to use two different CAs and as far as I see there is only one ssl_ca_file, I have tried to concatenate my certs as cert chain and use them, it seems to be working. Since it's not fully documented, do you think this approach won't cause any problems in the future? Generally, I need this because when I have multiple pg servers (primary and standby) I need to use SSL. So PG requires the standby represents a valid client cert, but the client cert ca I need to use for the standby can be different from the client cert ca that will be issuing the other certs that I will be giving to the standard users. Thanks, Duygu --00000000000086e9140633e87a29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,=C2=A0
I am trying to deploy a PG db with client = certificate auth. I have read the documentation, but I have a few questions= . One of my goals is to be able to use two different CAs and as far as I se= e there is only one ssl_ca_file, I have tried to concatenate my certs as ce= rt chain and use them, it seems to be working.=C2=A0
Since it's not= =C2=A0fully documented, do you think this approach won't cause any prob= lems in the future? Generally, I need this because when I have multiple=C2= =A0 pg servers (primary and standby) I need to use SSL. So PG requires the = standby represents a valid client cert, but the client cert ca I need to us= e for the standby can be different from the client cert ca that will be iss= uing the other certs that I will be giving=C2=A0to the standard users.=C2= =A0

Thanks,=C2=A0
Duygu=C2=A0
--00000000000086e9140633e87a29--