| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
| Cc: | sfrost(at)snowman(dot)net, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Is it worth accepting multiple CRLs? |
| Date: | 2021-01-15 07:56:27 |
| Message-ID: | 591fd449-f475-c2f1-0606-b2a47887c23f@enterprisedb.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2020-08-31 11:03, Kyotaro Horiguchi wrote:
> At Tue, 18 Aug 2020 16:43:47 +0900 (JST), Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote in
>> Thank you very much. I'll do that after some polishing.
>>
>> A near-by discussion about OpenSSL3.0 conflicts with this but it's
>> easy to follow.
>
> Rebased. Fixed bogus tests and strange tentative API change of
> SSLServer.pm. Corrected a (maybe) spelling mistake. I'm going to
> register this to the coming CF.
Other systems that offer both a CRL file and a CRL directory usually
specify those using two separate configuration settings. Examples:
https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_ssl_crlpath
https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcarevocationpath
These are then presumably both passed to X509_STORE_load_locations(),
which supports specifying a file and directory concurrently.
I think that would be a preferable approach. In practical terms, it
would allow a user to introduce the directory method gradually without
having to convert the existing CRL file at the same time.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2021-01-15 08:00:31 | Re: pg_upgrade test for binary compatibility of core data types |
| Previous Message | Kyotaro Horiguchi | 2021-01-15 07:54:33 | Re: Asynchronous Append on postgres_fdw nodes. |