Re: [PATCH] Log details for client certificate failures
Graham Leggett <minfrin@sharp.fm>
From: Graham Leggett <minfrin@sharp.fm>
To: Jacob Champion <jchampion@timescale.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2022-07-09T13:49:34Z
Lists: pgsql-hackers
On 01 Jul 2022, at 22:59, Jacob Champion <jchampion@timescale.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
—
Commits
-
Fix tiny memory leaks
- a9d58bfe8a3a 16.0 landed
-
Don't reflect unescaped cert data to the logs
- 257eb57b50f7 16.0 landed
-
pg_clean_ascii(): escape bytes rather than lose them
- 45b1a67a0fcb 16.0 landed
-
Log details for client certificate failures
- 3a0e385048ad 16.0 landed