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

From Jacob Champion
Subject Re: [PATCH] Log details for client certificate failures
Date
Msg-id CAAWbhmggsEacYW+cahN7USucsTgK9P4c5VMLaxWRdXvGQ=+BHA@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Log details for client certificate failures  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: [PATCH] Log details for client certificate failures
List pgsql-hackers
On Thu, Jun 30, 2022 at 2:43 AM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
>
> On 13.05.22 00:36, Jacob Champion wrote:
> > 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.

Sorry for the misunderstanding! v3 adds the Issuer to the logs as well.

I wanted to clarify that this "issuer" has not actually been verified,
but all I could come up with was "purported issuer" which doesn't read
well to me. "Claimed issuer"? "Alleged issuer"? Thoughts?

> 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 was about to say "yes, very cumbersome", but I actually think we
might be able to do that without bubbling the error up through
multiple callback layers, using SSL_set_ex_data() and friends. I'll
take a closer look.

Thanks!
--Jacob

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: postgres_fdw versus regconfig and similar constants
Next
From: Jacob Champion
Date:
Subject: Re: [PATCH] Log details for client certificate failures