Re: sslinfo extension - add notbefore and notafter timestamps
Daniel Gustafsson <daniel@yesql.se>
From: Daniel Gustafsson <daniel@yesql.se>
To: Jacob Champion <jchampion@timescale.com>
Cc: Cary Huang <cary.huang@highgo.ca>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2023-09-15T13:34:35Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Add notBefore and notAfter to SSL cert info display
- 6acb0a628ecc 17.0 landed
- 75ec5e7bec70 17.0 landed
-
Set fixed dates for test certificates validity
- 40fad96530ca 17.0 landed
Attachments
- v8-0001-Add-notBefore-and-notAfter-to-SSL-cert-info-displ.patch (application/octet-stream) patch v8-0001
> On 12 Sep 2023, at 21:40, Jacob Champion <jchampion@timescale.com> wrote: > > Hello, > > On 7/25/23 07:21, Daniel Gustafsson wrote: >> The attached version passes ssl tests for me on 1.0.2 through OpenSSL Git HEAD. > > Tests pass for me too, including LibreSSL 3.8. Thanks for testing! >> + /* Calculate the diff from the epoch to the certificat timestamp */ > > "certificate" Fixed. >> + <function>ssl_client_get_notbefore() returns text</function> >> ...> + <function>ssl_client_get_notafter() returns text</function> > > I think this should say timestamptz rather than text? Ditto for the > pg_stat_ssl documentation. > > Speaking of which: is the use of `timestamp` rather than `timestamptz` > in pg_proc.dat intentional? Will that cause problems with comparisons? It should be timestamptz, it was a tyop on my part. Fixed. > I haven't been able to poke any holes in the ASN1_TIME_to_timestamp() > implementations themselves. I went down a rabbit hole trying to find out > whether leap seconds could cause problems for us when we switch to > `struct tm` in the future, but it turns out OpenSSL rejects leap seconds > in the Validity fields. That seems weird -- as far as I can tell, RFC > 5280 defers to ASN.1 which defers to ISO 8601 which appears to allow > leap seconds -- but I don't plan to worry about it anymore. (I do idly > wonder whether some CA, somewhere, has ever had a really Unhappy New > Year due to that.) That's an interesting thought, maybe the CA's have adapted given the marketshare of OpenSSL? Thanks for reviewing, the attached v8 contains the fixes from this review along with a fresh rebase and some attempts at making tests more stable in the face of timezones by casting to date. -- Daniel Gustafsson