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

Inizio della pagina
Delete this message
Reply to this message
Autore: Axel Rau
Data:  
To: Phil Pennock
CC: Exim Dev
Oggetto: Re: [exim-dev] pgsql lookup TLS access broken in 4.82 RC2 ?

Am 07.10.2013 um 22:40 schrieb Phil Pennock <pdp@???>:

> On 2013-10-07 at 18:01 +0200, Axel Rau wrote:
>> All my mail servers use a pgsql lookup via TLS.
>> After upgrading to 4.82 RC2, I'm getting:
>> ---
>> …DEFER: PGSQL connection failed: SSL error: tlsv1 alert unknown ca
>
> This tells me that the certificate authority used to issue the
> certificate used by the Postgres server is not recognised by the SSL
> libraries used by Exim.
>
>> In the pgsql log:
>> ---
>> "could not accept SSL connection: no certificate returned",,,,,,,,,""
>
> That's the server logging the termination reason given by the client
> during its clean shutdown.
>
>> -r--r--r--  1 root      daemon  2565 Aug  4 14:14 ca_cert.pem
>> lrwxr-xr-x  1 root      daemon    31 Sep  8 17:51 postgresql.crt -> maileserver.at.some.domain_server_cert.pem
>> lrwxr-xr-x  1 root      daemon    30 Sep  8 17:51 postgresql.key -> maileserver.at.some.domain_server_key.pem
>> lrwxr-xr-x  1 root      daemon    11 Sep  8 17:51 root.crt -> ca_cert.pem

>
> Okay, and is that ca_cert.pem also used in the system SSL store?

What do you mean with system SSL store?
This same CA cert is being used by the pgsql server and exim for SMTP via TLS. Same with all other exim boxes running exim 4.80.
>
> Are you sure that nothing got updated in the Exim area? I note that the
> dates on those files are only a month ago: did someone deploy the change
> live and "fix" the certificate store live but not check the change into
> the SCM, so that spinning up an Exim box with an RC on it did not get
> the fix?

I'm sure.
>
>> Something has changed here or is broken in RC2.


>
> Compared to which release of Exim?

This is a test box (timap4). The last version, I tested was 4.80_217-60f8e1e-XX-4,
a version built from Jeremys git to test Experimental_TPDA.
That worked on 29-Jul, but now shows the same problem as RC2.
The pgsql lookup is being called from the SMTP transport (Experimental_TPDA).

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.


Now the good news:
RC2 on timap4 with same certs does valid outgoing SMTP via TLS:
---
(TLSv1:DHE-RSA-AES256-SHA:256)
---
I have installed RC2 on another box for incoming traffic (tmx4), which talks to the DB backend perfectly via TLS.
Here the pgsql lookup is being called from an acl.

>
> Agreed that if Exim is being more strict by default, then this needs to
> be called out in README.UPDATING as an issue. Note though that pgsql.c
> has not changed since the previous release and the only changes I know
> of around TLS behaviour relate specifically to the LDAP support.
>
> In fact, Exim doesn't do _any_ explicit initialisation of TLS for the
> pgsql lookup; we don't support using pgsql: schema URLs; we use an older
> API for initialisation, `PQsetdbLogin()`, and the only place we might
> supply the options is specified as NULL. So a PGOPTIONS environment
> variable will be honoured; is it possible that you have $PGOPTIONS
> defined in environ when starting the RC, but not in the system startup
> scripts?
>
> There have been a number of TLS changes, which _should_ relate only to
> TLS in SMTP, and were made to support cut-through delivery. As rampant
> speculation, I can hypothesize that Exim initialises TLS in OpenSSL
> differently and this now carries through to the use made by libpq of
> OpenSSL. But I don't think so.
>


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?

Axel
---
PGP-Key:29E99DD6 ☀ +49 151 2300 9283 ☀ computing @ chaos claudius