Re: [PATCH] Log details for client certificate failures
От | Peter Eisentraut |
---|---|
Тема | Re: [PATCH] Log details for client certificate failures |
Дата | |
Msg-id | c60a8948-00a0-147d-75df-62699193371f@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Log details for client certificate failures (Jacob Champion <pchampion@vmware.com>) |
Ответы |
Re: [PATCH] Log details for client certificate failures
Re: [PATCH] Log details for client certificate failures |
Список | 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 по дате отправления: