On 24/11/15 07:21, Rob Gunther wrote:
> Received TLS cert status response, itself unverifiable
>
> It seems to occur when sending mail to some remote hosts.... but not all.
This is to do with the server cert presented by the remote MTA you're
sending to.
The cert is usable both for encryption and for authentication, if it
is valid. We investigate the validity by tracing a trust chain from
one of a set of trust anchors. Often this is a "well-known" set of
Certificate Authorities.
Certificates can be "revoked" - declared no longer valid before the
expiry date embedded in them. CA's do this by publishing lists of
revoked certs. The lists can be megabytes long, so you really don't
want to be fetching one of those and searching it every time. Scratch
that idea...
Version 2: Online Certificate Status (OCSP). You can ask
the CA any time for a current status of a cert they published.
Still a poor idea - you'd have to do it every TLS conn, it'd be
a big load on the CA - and (potentially) the CA can track you by
your lookups. Scratch that idea....
Version 3: OCSP stapling. The server MTA system can periodically
ask its CA for a recent "status" of its cert, and serve the proof to
you as part of the TLS startup, along with the cert. This stapled
status (or proof) is itself an object signed by the CA, so the server
MTA system cannot create or manipulate it (just like the cert is).
It has a quite limited lifetime (probably weeks rather than the
years that the cert might be valid for). And it also, implicitly,
has a trust chain leading to it so that you (the client starting
the TLS connection) can verify it.
This last bit is what is missing, with your error message. Your
system could not verify that cert-status, that the remote TLS
endpoint sent us.
Whether it's a disaster for you depends on how secure you need
to be, for the specific target MTA. For general-purpose operations
on the world-wide internet, well... it's no worse than cleartext.
It's also no worse than a (verified) cert and no cert-status.
--
Cheers,
Jeremy
