Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert - Mailing list pgsql-hackers
From | Jacob Champion |
---|---|
Subject | Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert |
Date | |
Msg-id | CAAWbhmiKjQVY_QbajEM6kwUxFHzagnJLh5T_=6D9_RaKzMB=OQ@mail.gmail.com Whole thread Raw |
In response to | Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert (Jacob Champion <jchampion@timescale.com>) |
Responses |
Re: [PATCH] Add `verify-system` sslmode to use system CA pool for server cert
|
List | pgsql-hackers |
On Fri, Dec 2, 2022 at 9:58 AM Jacob Champion <jchampion@timescale.com> wrote: > Thanks for the nudge -- running with OpenSSL 3.0.7 in CI did not fix > the issue. I suspect a problem with our error stack handling... It is a problem with the error queue, but *whose* problem is probably up for debate. The queue looks like this after SSL_connect() returns: error:16000069:STORE routines:ossl_store_get0_loader_int:unregistered scheme:crypto/store/store_register.c:237:scheme=file error:80000002:system library:file_open:No such file or directory:providers/implementations/storemgmt/file_store.c:269:calling stat(/usr/local/etc/openssl@3/certs) error:16000069:STORE routines:ossl_store_get0_loader_int:unregistered scheme:crypto/store/store_register.c:237:scheme=file error:80000002:system library:file_open:No such file or directory:providers/implementations/storemgmt/file_store.c:269:calling stat(/usr/local/etc/openssl@3/certs) error:16000069:STORE routines:ossl_store_get0_loader_int:unregistered scheme:crypto/store/store_register.c:237:scheme=file error:80000002:system library:file_open:No such file or directory:providers/implementations/storemgmt/file_store.c:269:calling stat(/usr/local/etc/openssl@3/certs) error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:1883: Note that the error we care about is at the end, not the front. We are not the first using Homebrew to run into this, and best I can tell, it is a brew-specific bug. The certificate directory that's been configured isn't actually installed by the formula. (A colleague here was able to verify the same behavior on their local machine, so it's not a Cirrus problem.) The confusing "unrecognized scheme" message has thrown at least a few people off the scent. That refers to an OpenSSL STORE URI, not the URI describing the peer. (Why `file://` is considered "unregistered" is beyond me, considering the documentation says that file URI support is built into libcrypto.) From inspection, that error is put onto the queue before checking to see if the certificate directory exists, and then it's popped back off the queue if the directory is found(?!). Unfortunately, the directory isn't there for Homebrew, which means we get both errors, the first of which is not actually helpful. And then it pushes the pair of errors two more times, for reasons I haven't bothered looking into yet. Maybe this is considered an internal error caused by a packaging bug, in which case I expect the formula maintainers to ask why it worked for 1.1. Maybe it's a client error because we're not looking for the best error on the queue, in which case I ask how we're supposed to know which error is the most interesting. (I actually kind of know the answer to this -- OpenSSL's builtin clients appear to check the front of the queue first, to see if it's an SSL-related error, and then if it's not they grab the error at the end of the queue instead. To which I ask: *what?*) Maybe clients are expected to present the entirety of the queue. But then, why are three separate copies of the same errors spamming the queue? We can't present that. I'm considering filing an issue with OpenSSL, to see what they suggest a responsible client should do in this situation... > Separately from this, our brew cache in Cirrus is extremely out of > date. Is there something that's supposed to be running `brew update` > (or autoupdate) that is stuck or broken? (If this is eventually considered a bug in the formula, we'll need to update to get the fix regardless.) --Jacob
pgsql-hackers by date: