6

On my internet-facing Postfix SMTP server running Debian Wheezy, I'd like to set up a secure connection with some known servers. Some are my own, running my own PKI/CA, some are public SMTP servers like Google's Gmail servers. To check the certificates on the servers I'm running myself, I've specified

smtp_tls_CAfile = /usr/local/share/ca-certificates/Gert_van_Dijk_Root_CA_2014.crt

and to make sure the public servers can also be verified against the built-in system certificate store, I've explicitly specified

tls_append_default_CA = yes

In order to make sure Postfix verifies the certificate properly I've set the global TLS security level to 'secure'. I will change this back to 'may' with some domains to secure in smtp_tls_policy_maps once I've finished debugging this issue described here.

smtp_tls_security_level = secure

It verifies my own servers just fine! Those are all running with certificates signed by the Gert_van_Dijk_Root_CA_2014.crt. However, it appears the SMTP client does not actually append the certificates by the tls_append_default_CA setting when it tries to deliver mails to Google's SMTP servers. I would expect it to append those from /etc/ssl/certs on Debian.

postfix/smtp[32271]: effective TLS level: secure
[...]
postfix/smtp[32271]: < alt1.gmail-smtp-in.l.google.com[64.233.164.26]:25: 220 2.0.0 Ready to start TLS
[...]
postfix/smtp[32271]: DE6D0403EB: Server certificate not verified

Here's what I've tried:

  • Disabling chroot in master.cf for the smtp client like this:

    smtp      unix  -       -       n      -       -       smtp

    Didn't help.

  • Add verbose logging. I've added -v to the line above. Had to disable rsyslog rate limiting, but that didn't improve anything. The very one line it mentions about TLS verification is the DE6D0403EB: Server certificate not verified line.

  • Trying to strace the process to see if it bumps into any issue accessing the CA certificates. It appears the SMTP client is spawned as a new process for every delivery attempt. This makes the general strace -p <PID> impossible.

  • Search for similar problems. I only seem to find this very similar issue, but that's about not specifying the smtp_tls_CAfile setting, which I do. With a smtp_tls_CAfile set, it should really append the system-wide CA certs.

  • Reverting all back to Debian defaults, with the exception to smtp_tls_security_level = secure. It fails too in delivering to Google with the very same error. Bug in Debian's Postfix then?

  • Same as above, then disabling chroot for SMTP client and then set smtp_tls_CApath = /etc/ssl/certs explicitly. Still fails on certificate verification.

  • Adding TLS debugging level. Shows:

    postfix/tlsmgr[17486]: write smtp TLS cache entry smtp:64.233.164.26:25:mx.google.com&p=1&c=aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL&l=268439647: time=1421622891 [data 1975 bytes]
postfix/smtp[17485]: alt1.gmail-smtp-in.l.google.com[64.233.164.26]:25: subject_CN=mx.google.com, issuer_CN=Google Internet Authority G2, fingerprint 88:C0:85:C8:CB:96:29:8F:4E:15:11:80:C5:9A:89:0D, pkey_fingerprint=E0:32:29:21:69:38:EA:F9:B6:0C:F6:BD:86:12:16:B9
postfix/smtp[17485]: Untrusted TLS connection established to alt1.gmail-smtp-in.l.google.com[64.233.164.26]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
postfix/smtp[17485]: DE6D0403EB: Server certificate not trusted

  • OpenSSL manual verification on the same system shows everything really should be fine.

    $ openssl s_client -connect 64.233.164.26:25 -starttls smtp
CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0

  • With also disabling chroot for tlsmgr I've FINALLY got a Trusted TLS connection established, but then postfix still thinks the connection is insecure (Server certificate not verified): 

    postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: certificate verification depth=3 verify=1 subject=/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: certificate verification depth=2 verify=1 subject=/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: certificate verification depth=1 verify=1 subject=/C=US/O=Google Inc/CN=Google Internet Authority G2
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: certificate verification depth=0 verify=1 subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mx.google.com
postfix/smtp[27198]: SSL_connect:SSLv3 read server certificate A
postfix/smtp[27198]: SSL_connect:SSLv3 read server key exchange A
postfix/smtp[27198]: SSL_connect:SSLv3 read server done A
postfix/smtp[27198]: SSL_connect:SSLv3 write client key exchange A
postfix/smtp[27198]: SSL_connect:SSLv3 write change cipher spec A
postfix/smtp[27198]: SSL_connect:SSLv3 write finished A
postfix/smtp[27198]: SSL_connect:SSLv3 flush data
postfix/smtp[27198]: SSL_connect:SSLv3 read server session ticket A
postfix/smtp[27198]: SSL_connect:SSLv3 read finished A
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: aspmx.l.google.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: alt1.aspmx.l.google.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: alt2.aspmx.l.google.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: alt3.aspmx.l.google.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: alt4.aspmx.l.google.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: gmail-smtp-in.l.google.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: alt1.gmail-smtp-in.l.google.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: alt2.gmail-smtp-in.l.google.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: alt3.gmail-smtp-in.l.google.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: alt4.gmail-smtp-in.l.google.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: gmr-smtp-in.l.google.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: alt1.gmr-smtp-in.l.google.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: alt2.gmr-smtp-in.l.google.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: alt3.gmr-smtp-in.l.google.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: alt4.gmr-smtp-in.l.google.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: mx.google.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: aspmx2.googlemail.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: aspmx3.googlemail.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: aspmx4.googlemail.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subjectAltName: aspmx5.googlemail.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25 CommonName mx.google.com
postfix/smtp[27198]: gmail-smtp-in.l.google.com[173.194.67.26]:25: subject_CN=aspmx.l.google.com, issuer_CN=Google Internet Authority G2, fingerprint 88:C0:85:C8:CB:96:29:8F:4E:15:11:80:C5:9A:89:0D, pkey_fingerprint=E0:32:29:21:69:38:EA:F9:B6:0C:F6:BD:86:12:16:B9
postfix/smtp[27198]: Trusted TLS connection established to gmail-smtp-in.l.google.com[173.194.67.26]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
postfix/smtp[27198]: DE6D0403EB: Server certificate not verified

Is there a way to debug the SMTP client in Postfix running in the foreground? All debugging stuff appears to be regarding the smtpd process. :-(

Relevant further configuration:

# postconf -n | grep -E "^(smtp_|tls_)"
smtp_tls_CAfile = /usr/local/share/ca-certificates/Gert_van_Dijk_Root_CA_2014.crt
smtp_tls_security_level = secure
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
tls_append_default_CA = yes

# /etc/postfix/master.cf:
tlsmgr    unix  -       -       n       1000?   1       tlsmgr
smtp      unix  -       -       n       -       -       smtp -v
Improve this question

1 Answer 1

Reset to default
5

With smtp_tls_security_level = secure and default value of smtp_tls_secure_cert_match (smtp_tls_secure_cert_match = nexthop, dot-nexthop) postfix won't trust result from MX record. In other words postfix will use next-hop obtained from internal table like transport table.

That's why postfix still states Server certificate not verified. Postfix documentation clearly states that

Verified (peer certificate signed by trusted CA and verified peer name; or: peer certificate with expected public-key or certificate fingerprint)

Postfix SMTP client: The remote SMTP server's certificate was signed by a CA that the Postfix SMTP client trusts, and the certificate name matches the destination or server name(s). The Postfix SMTP client was configured to require a verified name, otherwise the verification status would have been just "Trusted".

You may to reduce the smtp_tls_security_level to verified so postfix will trusted the result of MX record and use it to verifying process. Another way was described in postfix documentation.

  • Secure-channel TLS without transport(5) table overrides

    Postfix will use smtp_tls_policy_maps to do verifying process.

  • Secure-channel TLS with transport(5) table overrides:

    In this case traffic to example.com and its related domains is sent to a single logical gateway (to avoid a single point of failure, its name may resolve to one or more load-balancer addresses, or to the combined addresses of multiple physical hosts). All the physical hosts reachable via the gateway's IP addresses have the logical gateway name listed in their certificates.

Improve this answer
3
  • 'In other words postfix will use next-hop obtained from internal table like transport table.' Ah, that's probably a wrong assumption by me that could be the cause. Will test and report back later today.
    – gertvdijk
    Jan 19, 2015 at 11:15
  • If you want see the example, go to postfix.org/TLS_README.html#client_tls_secure
    – masegaloeh
    Jan 19, 2015 at 11:28
  • Your answer is totally valid --thanks! I missed the point of the 'secure' policy, specifically regarding the nexthop meaning. However, the tls_append_default_CA configuration option together with a smtp_tls_CAfile = /path/to/myca.crt appears not to work in Debian at all. I had to supply smtp_tls_CApath = /etc/ssl/certs for system-wide CA certificates to be included.
    – gertvdijk
    Jan 19, 2015 at 21:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .