On Fri, Aug 14, 2020 at 02:30:03PM +0300, Thorsten Habich wrote:
> the certificate verification with TA file option still occasionally fails:
How is the use of a TA file relevant here?
> 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
Are you saying that the code doing the validation is unreliable, or is
the remote server merely presenting an unexpected certificate chain?
> 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)
Everything working otherwise correctly, so far.
> 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):
This is NOT "connection reuse". It is TLS session (server-side state or
client-side ticket) resumption:
> 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
As plainly noted in the above log entry.
> 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)
And evident from the *new* connection.
> 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)
Since resumed sessions don't involved presentation of a certificate
chain, the peer authentication status remains unchanged.
> 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)
And the client rejects the unauthenticated server. This condition will
clear once the session in question expires from the TLS session cache.
> In this example the remote side is using a Postfix 3.1. The problem is
> solved after a Postfix restart on our side.
This clears the TLS session cache.
> 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).
Perhaps you've not configured a TLS session cache.
----------------------------------------
On Fri, Aug 14, 2020 at 11:22:47AM -0400, Wietse Venema wrote:
> I'll leave it to Viktor and you to figure out why this is
> non-deterministic.
It looks deterministic enough to me. The only question is whether
Postfix should or should take steps to avoid caching sessions that fail
verification (at security levels > "encryption), or perhaps cache them
for a shorter time than default? Presently, these are cached in the
same way as regular sessions, and this has been the case for at least a
decade now.
> Unfortunately this does not show whether the SMTP client proceeds
> with the email delivery.
The client does not proceed as seen in one of the above log entries.
--
Viktor.
