Loading ...
Sorry, an error occurred while loading the content.

Re: How to check client certifications?

Expand Messages
  • Viktor Dukhovni
    ... Also http://www.postfix.org/postconf.5.html#check_ccert_access http://www.postfix.org/postconf.5.html#reject_plaintext_session That said, the text below
    Message 1 of 4 , Jun 12, 2013
    • 0 Attachment
      On Wed, Jun 12, 2013 at 03:23:38PM +0200, Jeroen Geilman wrote:

      > On 06/12/2013 03:02 PM, Peter Bauer wrote:
      > >
      > >How can I check the certificate of the incoming email? By
      > >fingerprint would be nice. And I would like to refuse it if check
      > >fails.
      >
      > http://www.postfix.org/TLS_README.html#server_vrfy_client

      Also

      http://www.postfix.org/postconf.5.html#check_ccert_access
      http://www.postfix.org/postconf.5.html#reject_plaintext_session

      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.

      http://www.postfix.org/TLS_README.html#client_tls_limits

      ...

      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
      organization.

      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
      the client.

      --
      Viktor.
    • Viktor Dukhovni
      ... This means the corresponding root CA was not in your CAfile or CApath, or the client configuration neglected to include the required intermediate CA
      Message 2 of 4 , Jun 12, 2013
      • 0 Attachment
        On Wed, Jun 12, 2013 at 03:02:40PM +0200, Peter Bauer wrote:

        > I got a connection from someone with a client certification:
        >
        > 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)

        This means the corresponding root CA was not in your CAfile or CApath, or
        the client configuration neglected to include the required intermediate CA
        certificates.

        > I would like to verify the fingerprint of this client certificate
        > of the incoming connection.

        The fingerprint is always "verified", in the sense that its authenticity
        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 client
        > connection certificates (I mean incoming TLS connections).

        Check for what? See my previous post.

        --
        Viktor.
      Your message has been successfully submitted and would be delivered to recipients shortly.