Re: How to check client certifications?
- On Wed, Jun 12, 2013 at 03:23:38PM +0200, Jeroen Geilman wrote:
> On 06/12/2013 03:02 PM, Peter Bauer wrote:Also
> >How can I check the certificate of the incoming email? By
> >fingerprint would be nice. And I would like to refuse it if check
That said, the text below was written around 2005 (for Postfix
2.3), and remains equally applicable today. The OP's desire to
use TLS fingerprint security for "inbound" mail is largely misguided,
DKIM is likely a better option for message origin authentication
(and even that has limited benefits). TLS is a hop-by-hop
transmission-channel security mechanism, while origin authentication
is an end-to-end problem.
An important SMTP-specific observation is that a public MX host
is even more at the mercy of the SMTP client than is an HTTPS
server. Not only can it not enforce due care in the client's
use of TLS, but it cannot even enforce the use of TLS, because
TLS support in SMTP clients is still the exception rather than
the rule. One cannot, in practice, limit access to one's MX
hosts to just TLS-enabled clients. Such a policy would result
in a vast reduction in one's ability to communicate by email
with the world at large.
One may be tempted to try to enforce TLS for mail from specific
sending organizations, but this, too, runs into obstacles. One
such obstacle is that we don't know who is (allegedly) sending
mail until we see the "MAIL FROM:" SMTP command, and at that
point, if TLS is not already in use, a potentially sensitive
sender address (and with SMTP PIPELINING one or more of the
recipients) has (have) already been leaked in the clear. Another
obstacle is that mail from the sender to the recipient may be
forwarded, and the forwarding organization may not have any
security arrangements with the final destination. Bounces also
need to be protected. These can only be identified by the IP
address and HELO name of the connecting client, and it is
difficult to keep track of all the potential IP addresses or
HELO names of the outbound email servers of the sending
Consequently, TLS security for mail delivery to public MX hosts
is almost entirely the client's responsibility. The server is
largely a passive enabler of TLS security, the rest is up to
- On Wed, Jun 12, 2013 at 03:02:40PM +0200, Peter Bauer wrote:
> I got a connection from someone with a client certification:This means the corresponding root CA was not in your CAfile or CApath, or
> Received: from foo.bar (foo.bar [10.0.0.1])
> (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
> (Client CN "mail.foo.bar", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified))
> by myserver.com (Postfix) with ESMTPS id 62A9141C05A4
> for <me@...>; Wed, 12 Jun 2013 14:46:07 +0200 (CEST)
> My problem is the following entry in the header:
> -> (not verified)
the client configuration neglected to include the required intermediate CA
> I would like to verify the fingerprint of this client certificateThe fingerprint is always "verified", in the sense that its authenticity
> of the incoming connection.
is never in doubt. What would you like to do with an authentic fingerprint?
> At least it would be fine if the certificate could be checked.The validity of its trust chain was checked, and verification failed that's
what "not verified" means.
> I have not found any option how to tell postfix to check clientCheck for what? See my previous post.
> connection certificates (I mean incoming TLS connections).