On 8/20/2020 6:57 PM, Viktor Dukhovni wrote:
>
> You likely also have had some infrequent unreported issues validating
> "secure" destinations without a configured "tafile", that resolve
> after the cached session expires.
>
> This is relevant, but probably not 100% accurate, likely some domains
> also intermittently failed routine CAfile-based validation.
>
Thanks for the patch. There was no higher number of certificate
verification failures since I updated to Postfix 3.5.4.
Checking the logs of the last 8 days, there is only one "Server
certificate not trusted" error for a CApath-based configuration and 348
errors for TAfile based configurations.
The number of *CApath* (if that's relevant) based mandatory TLS
configurations per destination is currently FAR higher than the tafile
based configurations.
> Yes, try the below patch (Postfix 3.4 and 3.5 only, NOT NEEDED in
> earlier releases or in Postfix 3.6 or later).
I will get back to you and let you know if the patch helped. Since I
wasn't able to reproduce the problem on the test environment, this might
take a while.
> You're forgiven. :-)
Thanks :-)
On 6/20/2020 10:15 PM, Wietse Venema wrote:
>
> Demo: on a non-DNSSEC host, use "posttls-finger -X " for force
> tlsproxy usage, and specify the remote SMTP server's server's own
> self-signed certificate as the trust anchor.
>
> # posttls-finger -X -A spike.porcupine.org.pem -l secure spike.porcupine.org
>
Using the command as mentioned is causing:
posttls-finger: fatal: The -X and -r options are mutually exclusive
Hope this patch is suitable:
--- a/src/posttls-finger/posttls-finger.c 2019-02-12
14:17:45.000000000 +0100
+++ b/src/posttls-finger/posttls-finger.c.new 2020-08-21
09:15:04.256945675 +0200
@@ -1988,7 +1988,7 @@
msg_fatal("bad '-a' option value: %s", state->options.addr_pref);
#ifdef USE_TLS
- if (state->tlsproxy_mode && state->reconnect)
+ if (state->tlsproxy_mode && state->reconnect > 0)
msg_fatal("The -X and -r options are mutually exclusive");
#endif
