On Fri, Jan 07, 2022 at 05:47:55PM -0500, PGNet Dev wrote:
> > 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?
It could, if the sending MTA implements OCSP and honours the extension,
and does even with opportunistic TLS (Exim may have sufficient code for
this, but I don't know whether enforcement happens by default, even when
it would otherwise accept self-signed or otherwise untrusted or
non-matching certificates).
> 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?
Best to not solicit misbehaviour, even if typically nothing bad happens.
> 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.
This is expected and normal. Postfix has an empty set of trusted issuers
by default, which avoids wasting time verifying certificates when the
result is ignored anyway. You can use the "-F <CAfile>" and/or the
"-P <CApath>" options if you want to go through the motions of doing
WebPKI chain verification.
Absent DANE, this is all security theatre.
--
Viktor.
