Am 08.10.2013 um 08:05 schrieb Phil Pennock <[email protected]>: > On 2013-10-08 at 01:28 +0200, Axel Rau wrote: >> Am 07.10.2013 um 22:40 schrieb Phil Pennock <[email protected]>: >>> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
