Re: [PATCH] Log details for client certificate failures

From: Graham Leggett <minfrin(at)sharp(dot)fm>
To: Jacob Champion <jchampion(at)timescale(dot)com>
Cc: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Log details for client certificate failures
Date: 2022-07-09 13:49:34
Message-ID: 59BF2A64-05F6-4870-B7DB-3FE815682209@sharp.fm
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01 Jul 2022, at 22:59, Jacob Champion <jchampion(at)timescale(dot)com> wrote:

>> I added this to httpd a while back:
>>
>> SSL_CLIENT_CERT_RFC4523_CEA
>>
>> It would be good to interoperate.
>
> What kind of interoperation did you have in mind? Are there existing
> tools that want to scrape this information for observability?

This is for human troubleshooting.

> I think the CEA syntax might not be a good fit for this particular
> patch: first, we haven't actually verified the certificate, so no one
> should be using it to assert certificate equality (and I'm truncating
> the Issuer anyway, to avoid letting someone flood the logs). Second,
> this is designed to be human-readable rather than machine-readable.

This is what a CEA looks like:

{ serialNumber 400410167207191393705333222102472642510002355884, issuer rdnSequence:”CN=Foo UK G1,O=Foo,C=UK" }

Whitespace and escaping is important above.

When troubleshooting, you want a string like the above that you can cut and paste and search for in other systems and log files. The verification status of the cert isn’t an issue at this point, you have a system in front of you where it doesn’t work when it should, and you need to know exactly what’s connecting, not what you think you’re connecting to, and you need precise data.

Please don’t invent another format, or try and truncate the data. This is a huge headache when troubleshooting.

Regards,
Graham

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zhihong Yu 2022-07-09 13:53:30 Re: Making the subquery alias optional in the FROM clause
Previous Message Dean Rasheed 2022-07-09 12:17:53 Re: Making the subquery alias optional in the FROM clause