Re: [exim-dev] pgsql lookup TLS access broken in 4.82 RC2 ?

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Phil Pennock
Datum:  
To: Axel Rau
CC: Exim Dev
Betreff: Re: [exim-dev] pgsql lookup TLS access broken in 4.82 RC2 ?
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.

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