Hello,
the certificate verification with TA file option still occasionally fails:
2020-08-13T07:39:39.007186+02:00 server postfix/tlsproxy[47119]:
certificate verification failed for remote.domain.tld[10.11.12.13]:25:
untrusted issuer /C=PL/O=Unizeto Sp. z o.o./CN=Certum CA
2020-08-13T07:39:39.007423+02:00 server postfix/tlsproxy[47119]:
Untrusted TLS connection established to
remote.domain.tld[10.11.12.13]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
2020-08-13T07:39:39.007537+02:00 server postfix/smtp[26187]: Untrusted
TLS connection established to remote.domain.tld[10.11.12.13]:25: TLSv1.2
with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
on the next delivery attempt the connection re-use seem to lead to the
fact that the verification isn't processed again, although the last
delivery attempt failed due to a mandatory TLS configuration (secure):
2020-08-13T07:47:55.233536+02:00 server postfix/tlsproxy[58527]:
remote.domain.tld[10.11.12.13]25: re-using session with untrusted
certificate, look for details earlier in the log
2020-08-13T07:47:55.233633+02:00 server postfix/tlsproxy[58527]:
Untrusted TLS connection established to
remote.domain.tld[10.11.12.13]:25: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
2020-08-13T07:47:55.233705+02:00 server postfix/smtp[44608]: Untrusted
TLS connection established to remote.domain.tld[10.11.12.13]:25: TLSv1.2
with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
2020-08-13T07:47:55.235003+02:00 server postfix/smtp[44608]: 123QUEUEID:
to=<lo...@domain.tld>, relay=remote.domain.tld[10.11.12.13]:25,
delay=497, delays=496/0/0.12/0, dsn=4.7.5, status=deferred (Server
certificate not trusted)
In this example the remote side is using a Postfix 3.1. The problem is
solved after a Postfix restart on our side.
Another remote MTA which is configured with TA file option, doesn't seem
to support connection re-use. ("re-using session with untrusted
certificate, look for details earlier in the log" is not mentioned in
our logs).
Mail delivery to this MTA frequently fails due to certificate validation
problems but mails are being delivered on the next attempt.
We are now using Postfix 3.5.4 on our side. Any further information I
can provide on this?
Kind regards
Thorsten
On 6/22/2020 4:44 PM, Wietse Venema wrote:
> Thorsten Habich:
>> On 6/20/2020 10:15 PM, Wietse Venema wrote:
>>> diff '--exclude=man' '--exclude=html' '--exclude=README_FILES'
>>> '--exclude=INSTALL' '--exclude=.indent.pro' -r -ur
>>> /var/tmp/postfix-3.6-20200610/src/tlsproxy/tlsproxy.c
>>> src/tlsproxy/tlsproxy.c
>>> --- /var/tmp/postfix-3.6-20200610/src/tlsproxy/tlsproxy.c 2020-05-15
>>> 09:29:14.000000000 -0400
>>> +++ src/tlsproxy/tlsproxy.c 2020-06-20 14:55:59.216357419 -0400
>>> @@ -997,12 +997,12 @@
>>> state->client_start_props->ctx = state->appl_state;
>>> state->client_start_props->fd = state->ciphertext_fd;
>>> /* These predicates and warning belong inside tls_client_start(). */
>>> - if (!TLS_DANE_BASED(state->client_start_props->tls_level)
>>> - || tls_dane_avail())
>>> - state->tls_context = tls_client_start(state->client_start_props);
>>> - else
>>> + if (!tls_dane_avail() /* mandatory side effects!! */
>>> + &&TLS_DANE_BASED(state->client_start_props->tls_level))
>>> msg_warn("%s: DANE requested, but not available",
>>> state->client_start_props->namaddr);
>>> + else
>>> + state->tls_context = tls_client_start(state->client_start_props);
>>> if (state->tls_context != 0)
>>> return (TLSP_STAT_OK);
>> I applied this patch too and everything seems to be working now, thanks!
>>
>> Will both patches (connection_reuse in tls policy map and tafile with
>> connection reuse on) be part of 3.5.4?
> Yes. All supported stable releases that have this problem. However
> the last stable release was a week ago. I prefer to wait another
> week.
>
> Wietse
