On Tue, Mar 05, 2019 at 04:02:36AM +0500, Mike Kazantsev wrote:
> And logs only show two kinds of messages on delivery:
>
> postfix/smtp[16394]: initializing the client-side TLS engine
> postfix/smtp[16393]: 869C7A23AD: TLS is required, but our TLS engine is
> unavailable
>
> Neither of these tells me what the problem with TLS engine was, and why
> it stopped working in 3.4.0, which I think is the main problem here.
The reason there's no logging of a problem, is that there is no
problem to log! :-( The certificate initialization was successful,
but due to a bug in reporting success/failure to the caller, the
successful outcome was treated as a failure (whose reason would
have already been logged if it were a real failure).
The patch is a one liner, below.
--- a/src/tls/tls_certkey.c
+++ b/src/tls/tls_certkey.c
@@ -589,7 +589,7 @@ static int set_cert_stuff(SSL_CTX *ctx, const char
*cert_type,
* single pass, avoiding potential race conditions during key rollover.
*/
if (strcmp(cert_file, key_file) == 0)
- return (load_mixed_file(ctx, cert_file));
+ return (load_mixed_file(ctx, cert_file) == 0);
/*
* We need both the private key (in key_file) and the public key
A work-around is to make symlink to the cert file and use that as
the keyfile.
# ln -s /etc/ssl/mail-relay-auth.pem /etc/ssl/mail-relay-key.pem
# postconf -e 'smtp_tls_eckey_file = /etc/ssl/mail-relay-key.pem
The bug is in the code that tries to import a single file with both
the key and the certificate in one go. Or rather, in the code that
calls that code (the underlying code was carefully tested, but the
calling code escaped unscrutinized). The official patch will have
a more comprehensive test.
--
Viktor.
