Am 08.10.2013 um 08:05 schrieb Phil Pennock <pdp@???>:
> On 2013-10-08 at 01:28 +0200, Axel Rau wrote:
>> Am 07.10.2013 um 22:40 schrieb Phil Pennock <pdp@???>:
>>> Okay, and is that ca_cert.pem also used in the system SSL store?
>> What do you mean with system SSL store?
>
> Run { openssl version -a }, take the "OPENSSLDIR" value and tack
> "/certs" onto the end. That's the default CApath used by OpenSSL and
> OpenSSL applications, assuming that neither $SSL_CERT_DIR nor
> $SSL_CERT_FILE is defined in the environment of the process.
This is /etc/certs on a vanilla FreeBSD installation, but the directory
has to be created.
>
> The directory (/usr/lib/ssl/certs or /usr/local/openssl/certs or
> whatever, but usually ends up pointing to /etc/ssl/certs via symlinks)
> contains the "trusted certificate authorities", used for verifying
> presented certificates; as a directory, it has files with the PEM
> certificates for each root CA, and then symlinks to those files with
> names based on a hash of some of the certificate contents, and then a
> uniqueness chain number, starting at 0. Those are normally maintained
> by the c_rehash command.
There is no such command. I used:
for file in *.pem; do ln -s $file `openssl x509 -hash -noout -in $file`.0; done
But it did not resolve the problem.
>
> The hash algorithm used changes with OpenSSL 1.0.0; if you've been
> experimenting with OpenSSL 1 lately, that might be something to
> investigate. I use a modified c_rehash command which maintains the
> symlinks with both the new and the old hashes, so:
>
> lrwxr-xr-x 1 root wheel 17 May 28 01:54 590d426f.0 -> cacert-class3.pem
> -rw-r--r-- 1 root wheel 2610 Nov 18 2011 cacert-class3.pem
> lrwxr-xr-x 1 root wheel 17 May 28 01:54 e5662767.0 -> cacert-class3.pem
>
> If you have cacert.org's class3 cert in your store, then the e5662767
> symlink is the one needed for 0.x versions of OpenSSL.
>
>>> Compared to which release of Exim?
>> This is a test box (timap4). The last version, I tested was 4.80_217-60f8e1e-XX-4,
>
> Nothing since then should have touched postgres support.
>
>> Meantime 2 things have changed:
>> 1. 51224 Aug 31 10:30 /usr/lib/libssl.so.6 ( A FreeBSD security update )
>> 2. ca_cert and server certs.
>
>> Looking at the PostgreSQL documentation here
>> http://www.postgresql.org/docs/9.3/static/libpq-ssl.html
>> I find this near the end of the page (31.18.5. SSL Library Initialization):
>> ---
>> PQinitOpenSSL
>> Allows applications to select which security libraries to initialize.
>>
>> void PQinitOpenSSL(int do_ssl, int do_crypto);
>>
>> When do_ssl is non-zero, libpq will initialize the OpenSSL library before first opening a database connection. When do_crypto is non-zero, thelibcrypto library will be initialized. By default (if PQinitOpenSSL is not called), both libraries are initialized. When SSL support is not compiled in, this function is present but does nothing.
>>
>> If your application uses and initializes either OpenSSL or its underlying libcrypto library, you must call this function with zeroes for the appropriate parameter(s) before first opening a database connection. Also be sure that you have done that initialization before opening a database connection.
>> ---
>> Could it be, that my problem has to do with that initialization?
>
> Possible, but we've changed nothing here. Please do try modifying
> src/lookups/pgsql.c to call this. Perhaps something like this:
>
> static void
> exim_pg_init()
> {
> static BOOL done;
>
> if (!done) {
> PQinitOpenSSL(0, 0);
> done = TRUE;
> }
> }
>
> and then call exim_pg_init() from near the start of
> perform_pgsql_search(). If this makes a difference, disabling crypto,
> then something hinky is going on if this ever worked for you before.
>
I will try this next.
Axel
---
PGP-Key:29E99DD6 ☀ +49 151 2300 9283 ☀ computing @ chaos claudius
