Re: [PATCH] Log details for client certificate failures - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [PATCH] Log details for client certificate failures
Date
Msg-id c60a8948-00a0-147d-75df-62699193371f@enterprisedb.com
Whole thread Raw
In response to Re: [PATCH] Log details for client certificate failures  (Jacob Champion <pchampion@vmware.com>)
Responses Re: [PATCH] Log details for client certificate failures  (Graham Leggett <minfrin@sharp.fm>)
Re: [PATCH] Log details for client certificate failures  (Jacob Champion <jchampion@timescale.com>)
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: Hamid Akhtar
Date:
Subject: Re: Allow pageinspect's bt_page_stats function to return a set of rows instead of a single row
Next
From: Graham Leggett
Date:
Subject: Re: [PATCH] Log details for client certificate failures