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.
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.
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.
-Phil
pgpMAnzT0hWNc.pgp
Description: PGP signature
-- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
