Re: [PATCH] Log details for client certificate failures

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Jacob Champion <pchampion(at)vmware(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Log details for client certificate failures
Date: 2022-05-04 13:53:27
Message-ID: 290871e5-f1d9-54a8-5df4-dbd9e604c08d@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 04.05.22 01:05, Jacob Champion wrote:
> On Tue, 2022-05-03 at 21:06 +0200, Peter Eisentraut wrote:
>> The information in pg_stat_ssl is limited to NAMEDATALEN (see struct
>> PgBackendSSLStatus).
>>
>> It might make sense to align what your patch prints to identify
>> certificates with what is shown in that view.
>
> Sure, a max length should be easy enough to do. Is there a reason to
> limit to NAMEDATALEN specifically? I was under the impression that we
> would rather not have had that limitation in the stats framework, if we
> could have avoided it. (In particular I think NAMEDATALEN will cut off
> the longest possible Common Name by just five bytes.)

Just saying that cutting it off appears to be acceptable. A bit more
than 63 bytes should be okay for the log.

In terms of aligning what is printed, I meant that pg_stat_ssl uses the
issuer plus serial number to identify the certificate unambiguously.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-05-04 13:56:13 Re: bogus: logical replication rows/cols combinations
Previous Message Tom Lane 2022-05-04 13:40:03 Re: Add pg_strtoupper and pg_strtolower functions