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

Always "Untrusted TLS" for own Postfix instances

Expand Messages
  • Dirk Stöcker
    Hello, I m lost and don t find any solution anymore, so I now need to ask. I m running three mail-servers with Postfix 2.9.6 (valid TLS cert), 2.7.2
    Message 1 of 63 , Feb 23, 2014
    • 0 Attachment
      Hello,

      I'm lost and don't find any solution anymore, so I now need to ask.

      I'm running three mail-servers with Postfix 2.9.6 (valid TLS cert), 2.7.2
      (self-signed), 2.11.0 (self-signed).

      And whatever I do I'm unable to get any of these three to show a trusted
      connection to any of the others. It trusts Google and GMX and whatever,
      but not my own servers. That's disturbing.

      Here the configs I use essentially

      smtpd_tls_loglevel = 1
      smtpd_tls_received_header = yes
      smtpd_tls_security_level = may
      smtpd_tls_cert_file = ...cert file include cert and all related ca's...
      smtpd_tls_key_file = ...key...
      smtpd_tls_CApath = /etc/ssl/certs/

      smtp_tls_loglevel = 1
      smtp_tls_security_level = may
      smtpd_tls_CApath = /etc/ssl/certs/

      The certificates are installed and

      openssl s_client -debug -connect ...server...:25 -starttls smtp

      also says that certificate chain is complete and valid. But Postfix tells
      me "Untrusted" when sending a mail to one of the others. Always. It's
      disturbing.

      Using a higher loglevel for TLS it seems that the other servers like
      Google send the certificates in initial connection of TLS, but my Postfix
      instances don't do this. And due to "may" Postfix sender seems not to ask.

      But even if it is not necessary to have a valid certificate installed for
      sending, I at least want to have the status correct in the logfile, so I
      can see a MITM attack in the log afterwards.

      Any ideas what's wrong with my setup or how I can bring Postfix to log the
      correct trust status even if "may" is used?

      Two of the servers are the one for this mail: mail.stoecker.eu and another
      one with a valid cert: josm.openstreetmap.de in case it helps to have a
      look.

      Ciao
      --
      http://www.dstoecker.eu/ (PGP key available)
    • /dev/rob0
      ... I hate to admit it, but this is true. :) BIND 9.8 and 9.9 have nice maintain features which prevent the poor administration problems. But with 9.7 and
      Message 63 of 63 , Feb 26, 2014
      • 0 Attachment
        On Wed, Feb 26, 2014 at 01:32:09PM -0500, Charles Marcus wrote:
        > Well, I sent them the two responses I got here (from rob0 and
        > Victor), and, in addition to what I think is the real reason,
        > here is what they came back with:
        >
        > >domains are more likely to go down do to poor DNSSEC
        > >administration than any domain will be down due to cache
        > >poisoning or the other hacks that DNSSEC is designed to prevent.

        I hate to admit it, but this is true. :)

        BIND 9.8 and 9.9 have nice "maintain" features which prevent the poor
        administration problems. But with 9.7 and earlier people were using
        semi-manual signing. Upgrade to a supported BIND version and you will
        have no problem; if you don't mind leaving your keys on the master
        server, that is.

        > >Have you actually heard of DNSSEC successfully stopping a hack
        > >yet? You probably haven not because it hasn't.

        It's also mostly true that serving bogus DNS data is not a common
        attack, NXDOMAIN hijacking being the exception. So anyway, you can
        counter that, "Yes, DNSSEC detects NXDOMAIN hijacking."

        > >Have you heard of DNSSEC causing downtime for domains? I am sure
        > >you have... because it happens often.

        As with anything, if you know what you're doing, it does not. I might
        also add that the terminology used, "downtime for domains" et c., is
        indicative of a non-professional. For what that's worth.

        > >This is way most of the largest domains do not support DNSSEC,
        > >nor will they.

        Funny if that is true, because the big guys are the most likely
        targets for DNS spoofing or hijacking attacks.

        > <sigh>
        >
        > Oh well, not an immediate problem, and their normal DNS service
        > is excellent (and really cheap - $29/yr for up to 10 domains)...

        I do still believe that DNSSEC adoption will increase, and with it
        the demand for clueful and capable DNS providers will rise.

        But I have to admit that these threads have shown a glimpse into
        other worlds. :) For me, when the root zone was signed, DNSSEC was
        something I had to do. I found that my Zoneedit nameservers didn't
        support it, so I removed them and went for self-hosting. It never
        occurred to me that "no DNSSEC" was an option. :)
        --
        http://rob0.nodns4.us/
        Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
      Your message has been successfully submitted and would be delivered to recipients shortly.