On 8/20/2020 6:01 PM, Viktor Dukhovni wrote: > I don't recall seeing any logging posted showing those initial > validation failures. This might be as good a time as any to address > that (the failure logs for the initial connection should have been part > of the post that started this thread).
Those are the logs from my first mail addressing the problem: 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) On the first delivery attempt there is not mentioned "re-using session with untrusted certificate, look for details earlier in the log" so I assumed that there was no session cached, is that assumption wrong? > I hope you're not still conflating session resumption with connection > reuse. If I got it right, the tlsproxy is only handling the certificate validation in case connection_reuse is on, I am actually neither assuming a session issue nor a connection reuse issue but somehow an issue with the certificate validation in tlsproxy. Which is why I want to check if the problem still occurs with connection_reuse=no off in the tls_policy_maps after I gathered some further logging with a higher log level. Is there any difference between turning connection reuse off in tls policy maps or in a transport so that the transport method should be preferred?
