Re: [PATCH] Log details for client certificate failures
Jacob Champion <jchampion@timescale.com>
From: Jacob Champion <jchampion@timescale.com>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-07-08T18:39:04Z
Lists: pgsql-hackers
Attachments
- since-v3.diff.txt (text/plain)
- v4-0001-Log-details-for-client-certificate-failures.patch (text/x-patch) patch v4-0001
- v4-0002-squash-Log-details-for-client-certificate-failure.patch (text/x-patch) patch v4-0002
On Thu, Jul 7, 2022 at 2:50 AM Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote: > I looked into how you decode the serial number. I have found some code > elsewhere that passed the result of X509_get_serialNumber() directly to > ASN1_INTEGER_set(). But I guess a serial number of maximum length 20 > octets wouldn't fit into a 32-bit long. (There is > ASN1_INTEGER_set_int64(), but that requires OpenSSL 1.1.0.) Does that > match your understanding? Yep. And the bit lengths of the serial numbers used in the test suite are in the low 60s already. Many people will just randomize their serial numbers, so I think BN_bn2dec() is the way to go. > For the detail string, I think we could do something like: > > DETAIL: Failed certificate data (unverified): subject '%s', serial > number %s, issuer '%s' Done that way in v4. I also added an optional 0002 that bubbles the error info up to the final ereport(ERROR), using errdetail() and errhint(). I can squash it into 0001 if you like it, or drop it if you don't. (This approach could be adapted to the client, too.) Thanks! --Jacob
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