Session ID resumption is by default disabled. This is a feature, let
the client store a session ticket if it wants, otherwise it does a fresh
handshake. This makes sense for SMTP.
OCSP stapling not offered
??? OCSP must staple extension requires OCSP stapling (NOT ok)
You made the mistake of using the "--must-staple" flag with certbot, or
some equivalent way to elicit this certificate feature.
bingo.
my generator wrapper script around acme.sh handled initial cert generation for
all my domains --
& has a default of
--ocsp-must-staple --ocsp
good for all the web certs. as you point out, not for postfix.
an oversight.
Don't do that.
+1 . an easy fix. thx.
Postfix has no CRL or OCSP support, and none is planned.
other than reporting the bad result, does the current (bad) config cause any
actual mail delivery breakage?
i've clearly not noticed my mistake 'til now, and afaict have seen no
unexplained breakage.
dunno if i should've and missed it, or it's just noisy and ignorable?
The other ??? item,
"Session Resumption Tickets: yes, ID resumption test failed, pls
report"
This is expected, nothing to worry about.
+1
Matt Caswell and I had a chat about this and session ticket issuance was
made more configurable and backwards-compatible in a subsequent OpenSSL
1.1.1 release. OpenSSL 1.1.1<sufficiently-recent-patch-level> and later
now honour the ticket callback signal to reuse the existing ticket. If
you observe something else, let me know.
Resumption with a previously obtained and still fresh ticket should not
elicit yet another ticket. Unless "posttls-finger" fails to log the
unwanted ticket this appears to still be working:
$ posttls-finger -Lssl-debug,verbose -r3 -c amnesiac
...
There's no "read server session ticket" logged after resumption.
Here, appears ~ the same
with
postconf mail_version
mail_version = 3.6.3
openssl version
OpenSSL 1.1.1l FIPS 24 Aug 2021
exec
posttls-finger -Lssl-debug,verbose -r3 -c mx.example.com
...
posttls-finger: certificate verification failed for
mx.example.com[192.0.2.12]:25: untrusted issuer /O=Digital Signature Trust
Co./CN=DST Root CA X3
posttls-finger: mx.example.com[192.0.2.12]:25:
subject_CN=mx.example.com, issuer_CN=R3, fingerprint=26:...:64
posttls-finger: SSL_connect:SSL negotiation finished successfully
posttls-finger: SSL_connect:SSL negotiation finished successfully
--> posttls-finger: SSL_connect:SSLv3/TLS read server session ticket
posttls-finger: Reconnecting after 3 seconds
posttls-finger: looking for session
[192.0.2.12]:25&103B4B1F4A5BBF379DCD2EE9B618B03309F956ED7A7D865743E12E6B275A6E95
in memory cache
posttls-finger: reloaded session
[192.0.2.12]:25&103B4B1F4A5BBF379DCD2EE9B618B03309F956ED7A7D865743E12E6B275A6E95
from memory cache
posttls-finger: SSL_connect:before SSL initialization
posttls-finger: SSL_connect:SSLv3/TLS write client hello
posttls-finger: SSL_connect:SSLv3/TLS write client hello
posttls-finger: SSL_connect:SSLv3/TLS read server hello
posttls-finger: SSL_connect:TLSv1.3 read encrypted extensions
posttls-finger: SSL_connect:SSLv3/TLS read finished
posttls-finger: SSL_connect:SSLv3/TLS write change cipher spec
posttls-finger: SSL_connect:SSLv3/TLS write finished
posttls-finger: mx.example.com[192.0.2.12]:25: Reusing old session
posttls-finger: mx.example.com[192.0.2.12]:25: re-using session with
untrusted certificate, look for details earlier in the log
posttls-finger: Untrusted TLS connection established to
mx.example.com[192.0.2.12]:25: TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256
(256/256 bits) key-exchange X25519 server-signature ECDSA (P-384)
posttls-finger: Found a previously used server. Done reconnecting.
, except for the
re-using session with untrusted certificate
which I need to investigate. my certs are LE-issued public certs. dunno yet why I've
got an "untrusted issuer" rattling around.
