On Sun, Feb 17, 2019 at 02:41:27PM +0100, A. Schulze wrote:
> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse" Now
> I notice delivery problems to "gervers.com".
The DNS configuration for this domain is:
gervers.com. IN MX 10 sys1.mmini.de. ; NoError AD=1
sys1.mmini.de. IN A 5.9.100.168 ; NoError AD=1
sys1.mmini.de. IN AAAA 2a01:4f8:162:32ac::2 ; NoError AD=1
_25._tcp.sys1.mmini.de. IN TLSA 3 1 1
69f3288e4797be2044e3cb6d0251e0fa28d986abcb4e2837863094d85d516161 ; NoError AD=1
_25._tcp.sys1.mmini.de. IN TLSA 2 1 1
60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 ; NoError AD=1
But the live Let's Encrypt certificate chain does not match the
(presumably stale) "3 1 1" TLSA record, so it remains for the "2 1
1" record to match the issuing CA, and that's why Postfix is doing
"CA verification":
sys1.mmini.de[5.9.100.168]: pass: TLSA match: depth = 1, name = sys1.mmini.de
TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384,P256
name = raketenstaffel.de
name = sys1.mmini.de
name = thegreendorf.de
name = www.raketenstaffel.de
name = www.thegreendorf.de
depth = 0
Issuer CommonName = Let's Encrypt Authority X3
Issuer Organization = Let's Encrypt
notBefore = 2019-01-20T00:30:26Z
notAfter = 2019-04-20T00:30:26Z
Subject CommonName = raketenstaffel.de
pkey sha256 [nomatch] <- 3 1 1
d090d27c5a4b92dfd3b6b6b548e88aee92c8ce739eba6b529780fa923d3ffbcc
depth = 1
Issuer CommonName = DST Root CA X3
Issuer Organization = Digital Signature Trust Co.
notBefore = 2016-03-17T16:40:46Z
notAfter = 2021-03-17T16:40:46Z
Subject CommonName = Let's Encrypt Authority X3
Subject Organization = Let's Encrypt
pkey sha256 [matched] <- 2 1 1
60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
which, as you noted, generally works. However:
> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: sys1.mmini.de[5.9.100.168]:25:
> re-using session with untrusted certificate, look for details earlier in
> the log
> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: Untrusted TLS connection
> established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Here, we see re-use of a cached TLS session to the destination that
failed to verify during the initial handshake. This is a combination
of both connection re-use (via tlsproxy(8)) and TLS session resumption
in tlsproxy itself.
> But I did not found anything special "earlier in the log" ...
>
> Message was delivered immediately as I disabled smtp_tls_connection_reuse:
> Feb 17 14:37:45 mail postfix/smtp[15157]: Verified TLS connection established
> to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher
> ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
If you performed a "reload" to get that to take effect, that would
also have flushed the TLS session cache. And perhaps disabling
connection re-use is a distraction. It may well have been sufficient
to just "postfix reload".
On Sun, Feb 17, 2019 at 03:38:19PM +0100, A. Schulze wrote:
> Feb 17 10:27:54 mail postfix/smtpd[9445]: 442M9Q3L8Kzkn:
> client=localhost[127.0.0.1]
> Feb 17 10:27:55 mail postfix/tlsproxy[9450]: CONNECT to [5.9.100.168]:25
> Feb 17 10:27:55 mail postfix/tlsproxy[9450]: CA certificate verification
> failed for sys1.mmini.de[5.9.100.168]:25: num=28:certificate rejected
This is more interesting. What OpenSSL version is your Postfix
linked with? The issuer certificate was *explicitly* rejected. At
first glance, that should only happen when not using DANE, and your
trust store has an issuer certificate for the chain, that is augmented
with trust settings (purpose OIDs) that don't include fitness for
use by TLS servers. That's rather uncommon.
Please post the outputs of "postconf -nf" and "postconf -Mf", and
information about the OpenSSL version, checking "ldd" to make sure
you're reporting the version of the correct library.
> the same tlsproxy process handled 5 other connections before this one. All
> logged as 'Untrusted TLS connection established to'
If you re-enable use of the proxy, does the problem come back?
On Sun, Feb 17, 2019 at 04:45:11PM +0100, A. Schulze wrote:
> > Can you confirm that the SMTP client will not deliver to this
> > destination with NEW and REUSED tlsproxy connections?
> cannot check that without bothering the receiver with annoying test messages.
> Will ask for permission...
You don't need to send messages that reach the recipient. You can
send "delivery probes" via:
sendmail -f your-address -bv recipient-address
These drop the connection after "RCPT TO", without delivering a message.
> that's the point I started with subject "DANE issue..."
> The destination don't need any certificate chains. The destination can be
> validated using DANE.
We might temporarily need to raise the TLS loglevel to 2 in the
proxy just before sending a delivery probe. It should then be
possible to see more of the TLS handshake details.
> > What is the output from:
> >
> > postconf -F smtp/unix/chroot tlsproxy/unix/chroot
> smtp/unix/chroot = y
> tlsproxy/unix/chroot = y
You should make sure your DNS is correctly configured in the chroot
jail. Are any of the upstream resolvers perhaps not configured to
do DNSSEC?
On Sun, Feb 17, 2019 at 06:44:02PM +0100, A. Schulze wrote:
> hard to say...
>
> delivery deferred if smtp_tls_connection_reuse = yes
> delivery works if smtp_tls_connection_reuse = no
That's not yet a valid analysis, the "re-use" could be unrelated.
--
Viktor.
