From: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
To: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
To: Jacob Champion <jchampion@timescale.com>
Subject: Re: [PATCH] Log details for client certificate failures
Date: Thu, 30 Jun 2022 10:43:21 +0100
Message-ID: <c60a8948-00a0-147d-75df-62699193371f@enterprisedb.com> (raw)
In-Reply-To: <9b8338210b865d79239ec35ca523792ce331c0a3.camel@vmware.com>
References: <d13c4a5787c2a3f83705124f0391e0738c796751.camel@vmware.com>
<cd03fa63-d4d9-8d3b-f9f5-13206a28d888@enterprisedb.com>
<a922e857c4e4a073f219bc5005b862eb22255c20.camel@vmware.com>
<290871e5-f1d9-54a8-5df4-dbd9e604c08d@enterprisedb.com>
<7c0468dcadbc0d0c987daf9ca08c8d111948eae6.camel@vmware.com>
<9b8338210b865d79239ec35ca523792ce331c0a3.camel@vmware.com>
On 13.05.22 00:36, Jacob Champion wrote:
> On Thu, 2022-05-05 at 15:12 +0000, Jacob Champion wrote:
>> On Wed, 2022-05-04 at 15:53 +0200, Peter Eisentraut wrote:
>>> In terms of aligning what is printed, I meant that pg_stat_ssl uses the
>>> issuer plus serial number to identify the certificate unambiguously.
>>
>> Oh, that's a great idea. I'll do that too.
>
> v2 limits the maximum subject length and adds the serial number to the
> logs.
I wrote that pg_stat_ssl uses the *issuer* plus serial number to
identify a certificate. What your patch shows is the subject and the
serial number, which isn't the same thing. Let's get that sorted out
one way or the other.
Another point, your patch produces
LOG: connection received: host=localhost port=44120
LOG: client certificate verification failed at depth 1: ...
DETAIL: failed certificate had subject ...
LOG: could not accept SSL connection: certificate verify failed
I guess what we really would like is
LOG: connection received: host=localhost port=44120
LOG: could not accept SSL connection: certificate verify failed
DETAIL: client certificate verification failed at depth 1: ...
failed certificate had subject ...
But I suppose that would be very cumbersome to produce with the callback
structure provided by OpenSSL?
I'm not saying the proposed way is unacceptable, but maybe it's worth
being explicit about this tradeoff.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: peter.eisentraut@enterprisedb.com, jchampion@timescale.com
Subject: Re: [PATCH] Log details for client certificate failures
In-Reply-To: <c60a8948-00a0-147d-75df-62699193371f@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox