On 8/19/2020 4:31 PM, Viktor Dukhovni wrote: > > Do *resumed* sessions always fail to validate? Or is that intermittent?
As far as I could see resumed sessions that failed keep failing (probably until the session cache expires) but I had to restart the Postfix most times before that happened. > When resumption fails, was the preceding non-resumed session successful? Yes. Other connections with tafile or with CApath configuration were successfully made. I saw a tlsproxy process with the same process ID which had a failed tafile based session and another successful non-tafile connection right afterwards. I think I will increase the debugging today and afterwards turn off connection_reuse for the tafile based configurations at least with Postfix <3.5.4 the verification only failed when connection_reuse was on. > > Have you considered as a differential diagnostic procedure setting up a > separate > transport for the problem domain, and using the trust-anchors in question as > the CAfile for the transport instead of a per-destination policy "tafile"? > > Are the trust-anchors self-signed CA certs, or are they "intermediate" certs > signed by some other CA? If intermediate, it takes a bit more effort to > turn them into a usable CAfile, because they'd need to be encapsulated > as "TRUSTED CERTIFICATE" PEM objects, with a trust EKU of "serverAuth". > I can post an example of how to do that if necessary. It would be nice if you could post an example. I need to discuss that with my colleagues. > Also, can you test the Postfix 3.6-20200725 snapshot? In Postfix 3.6 > the "tafile" code is based on the DANE support in OpenSSL 1.1.1, rather > than the older DANE certificate validation code in Postfix itself. I tried the same setup on a test system yesterday and weren't able to reproduce the problem. So I guess testing with Postfix 3.6 isn't possible until it's becoming stable. Is any backport for Postfix 3.5 possible? Am I right, that posttls-finger always fails verification with -A option?
