Always "Untrusted TLS" for own Postfix instances
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
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
http://www.dstoecker.eu/ (PGP key available)
- 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 andI hate to admit it, but this is true. :)
> 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.
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 hackIt's also mostly true that serving bogus DNS data is not a common
> >yet? You probably haven not because it hasn't.
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 sureAs with anything, if you know what you're doing, it does not. I might
> >you have... because it happens often.
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,Funny if that is true, because the big guys are the most likely
> >nor will they.
targets for DNS spoofing or hijacking attacks.
> <sigh>I do still believe that DNSSEC adoption will increase, and with it
> Oh well, not an immediate problem, and their normal DNS service
> is excellent (and really cheap - $29/yr for up to 10 domains)...
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. :)
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: