> On 12 Apr 2023, at 23:46, Daniel Gustafsson <dan...@yesql.se> wrote: >> On 12 Apr 2023, at 23:40, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> So this smells to me like a new OpenSSL bug: they should tolerate >> a missing certs dir like they used to. Who wants to file it? > > They are specifying that: "A missing default location is still treated as a > success". That leaves out the interesting bit of what a success means here, > and how it should work when verifications are requested. That being said, the > same is written in the 1.1.1 manpage. After a little bit of digging I have a vague idea. OpenSSL will treat a missing default location as a success simply due to the fact that it mainly just stores the path, loading of the certs is deferred until use (which maps well to the error we are seeing). Patching OpenSSL to report all errors makes no difference, a missing default is indeed not an error even with errors turned on. The change in OpenSSL 3 is the addition of certificate stores via ossl_store API. When SSL_CTX_set_default_verify_paths() is called it will in 1.1.1 set the default (hardcoded) filename and path; in 3 it also sets the default store. Stores are initialized with a URL, and the default store falls back to using the default certs dir as the URI as no store is set. If I patch OpenSSL 3 to skip setting the default store, the tests pass even with a missing cert directory. This is effectively the 1.1.1 behavior. The verification error we are hitting is given to us in the verify_cb which we've short circuited. The issue we have is that we cannot get PGconn in verify_cb so logging an error is tricky. I need to sleep on this before I do some more digging to figure out if OpenSSL considers this to be the intended behavior, a regression in 3, or if we have a bug in how we catch verification errors which is exposed by a non-existing store. I'll add an open item for this in the morning to track how we'd like to proceed. -- Daniel Gustafsson
