On Wed, Sep 29, 2021 at 02:25:16PM +0200, Bugz Bunny <[email protected]> wrote:
> Hello list, > > For the past 6 hours, I have not made any iota of progress towards > getting this to work. The certificate chain is Root CA > Intermediate > CA > Client and Server cert. The openssl x509 -text outputs for the > CA's are included in E-Mail attachments. > > postconf -n > postconf: warning: /etc/postfix/master.cf: undefined parameter: > submission_sender_restrictions You should define submission_sender_restrictions or remove the reference to it from master.cf. > alias_database = hash:/etc/aliases > alias_maps = hash:/etc/aliases > command_directory = /usr/sbin > daemon_directory = /usr/libexec/postfix > data_directory = /var/lib/postfix > debug_peer_level = 2 > debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd > $daemon_directory/$process_name $process_id & sleep 5 > header_checks = regexp:/etc/postfix/header_checks > html_directory = no > inet_protocols = all > mailq_path = /usr/bin/mailq.postfix > manpage_directory = /usr/share/man > milter_default_action = accept > mydestination = > mynetworks = 52.14.9.241/32 107.173.129.223/32 127.0.0.1/32 > newaliases_path = /usr/bin/newaliases.postfix > readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES Postfix 2.10 reached end of life over five years ago. Upgrading would be a great idea if at all possible. > relay_domains = lhprojects.net, lhpmail.us > relay_transport = smtp:smtp.lhpmail.us:587 The above should probably be smtp:[smtp.lhpmail.us]:587 to suppress an unnecessary MX lookup for smtp.lhpmail.us. > sample_directory = /usr/share/doc/postfix-2.10.1/samples > sender_canonical_maps = hash:/etc/postfix/sender_canonical_maps > sendmail_path = /usr/sbin/sendmail.postfix > setgid_group = postdrop > smtp_destination_concurrency_limit = 2 > smtp_destination_rate_delay = 5s > smtp_extra_recipient_limit = 10 > smtp_use_tls = yes > smtpd_banner = $myhostname - Connected to LHProjects Information Network > E-Mail Server > smtpd_milters = inet:127.0.0.1:11332 > smtpd_recipient_restrictions = permit_mynetworks permit_inet_interfaces > reject_unauth_destination > smtpd_tls_cert_file = /etc/ssl/postfix/mx.cert.pem > smtpd_tls_key_file = /etc/ssl/postfix/mx.key.pem > smtpd_tls_loglevel = 2 > unknown_local_recipient_reject_code = 550 You are setting smtpd_tls_cert_file and smtpd_tls_key_file but you are not setting "smtpd_tls_security_level = may" (or "smtpd_use_tls = yes"), so they won't be used for STARTTLS on port 25. You probably want to add "smtpd_tls_security_level = may". That's the modern equivalent of "smtpd_use_tls = yes". That will make it possible for incoming email on port 25 to be encrypted, not just outgoing mail (which is made possible by "smtp_use_tls = yes" or "smtp_tls_security_level = may"). > postconf -Mf > postconf: warning: /etc/postfix/master.cf: undefined parameter: > submission_sender_restrictions > smtp inet n - n - - smtpd > submission inet n - n - - smtpd > -o syslog_name=postfix/submission > -o smtpd_recipient_restrictions=permit_tls_clientcerts,reject > -o smtpd_tls_req_ccert=yes > -o smtpd_tls_auth_only=no > -o smtpd_tls_security_level=encrypt > -o smtpd_tls_cert_file=/etc/postfix/ssl/submission.cert > -o smtpd_tls_key_file=/etc/postfix/ssl/submission.key The above two parameters are overriding the corresponding parameters in main.cf for incoming mail on port 587. That's probably not what you are intending. Normally, you would just set these in main.cf so that the same certificate is used on ports 25 and 587. But perhaps you want two different certificates for the same purpose. That's not necessarily a problem (but see below). > -o smtpd_tls_fingerprint_digest=sha1 > -o relay_clientcerts=hash:/etc/postfix/relay_clientcerts > -o smtpd_relay_restrictions=permit_tls_clientcerts,reject > -o smtpd_tls_CAfile=/etc/postfix/ssl/ca_new2.pem > -o smtpd_sender_restrictions=$submission_sender_restrictions > -o smtpd_client_restrictions= > -o smtpd_helo_restrictions= > -o smtpd_data_restrictions= > pickup unix n - n 60 1 pickup > cleanup unix n - n - 0 cleanup > qmgr unix n - n 300 1 qmgr > tlsmgr unix - - n 1000? 1 tlsmgr > rewrite unix - - n - - trivial-rewrite > bounce unix - - n - 0 bounce > defer unix - - n - 0 bounce > trace unix - - n - 0 bounce > verify unix - - n - 1 verify > flush unix n - n 1000? 0 flush > proxymap unix - - n - - proxymap > proxywrite unix - - n - 1 proxymap > smtp unix - - n - - smtp > relay unix - - n - - smtp > showq unix n - n - - showq > error unix - - n - - error > retry unix - - n - - error > discard unix - - n - - discard > local unix - n n - - local > virtual unix - n n - - virtual > lmtp unix - - n - - lmtp > anvil unix - - n - 1 anvil > scache unix - - n - 1 scache > > Relevent logs: > > Sep 29 07:16:02 centos8mx-dev postfix/submission/smtpd[17603]: initializing > the server-side TLS engine > [...] > > I've manually double checked the the certificates over a dozens times, > search the internet for any information on how to correctly create > CA certs but AFAICT. Nothing seems amiss. While the error seems > obvious on the surface, it's extremely confusing to what's exactly > the cause of the error. Which certificate does it not like ? All this > is being on done on a test VM. openssl verify -purpose sslclient > doesn't complain, I'm able to create and sign certs with those CA > certificates? What is it exactly that's breaking down here? Any > pointers would be greatly appreciated here. The main problem is that you are using two different certificates for the same purpose (server), but you seem to have created one for server use and the other one for client use. >From main.cf: smtpd_tls_cert_file = /etc/ssl/postfix/mx.cert.pem smtpd_tls_key_file = /etc/ssl/postfix/mx.key.pem >From master.cf: -o smtpd_tls_cert_file=/etc/postfix/ssl/submission.cert -o smtpd_tls_key_file=/etc/postfix/ssl/submission.key Both of these need to pass the "openssl verify -purpose sslserver ..." test because they are both being used by the smtp server. Actually, the first ones aren't being used at all, because main.cf doesn't contain "smtpd_use_tls = yes" or "smtpd_tls_security_level = may", so the specifications of smtpd_tls_cert_file and smtpd_tls_key_file are never used. That means that STARTTLS is never offered on port 25. The only time STARTTLS is offered is on the submission port, and the certificate used by the server in that case is the one specified in master.cf. Passing the "openssl verify -purpose sslclient ..." test is only appropriate for the smtp_tls_cert_file parameter (i.e. used by the local postfix smtp client for outgoing mail), which you aren't using anywhere. The certificate in smtpd_tls_cert_file is being used by the local postfix smtp server for incoming mail. Was your intention to use submission.cert as a client certificate when making outgoing connections to the relay_transport (smtp:smtp.lhpmail.us:587)? If so, remove smtpd_tls_cert_file and smtpd_tls_key_file from master.cf and put this in main.cf instead: smtp_tls_cert_file=/etc/postfix/ssl/submission.cert smtp_tls_key_file=/etc/postfix/ssl/submission.key Note the "smtp_" prefix for the smtp client, not the "smtpd_" prefix for the smtp server. Is this making any sense? When you want the postfix smtp server to offer STARTTLS for incoming mail (any port), you usually want this in main.cf: smtpd_tls_security_level = may smtpd_tls_key_file = /etc/ssl/postfix/mx.key.pem smtpd_tls_cert_file = /etc/ssl/postfix/mx.cert.pem But you are missing the smtpd_tls_security_level parameter in main.cf, so that certificate is unused. When you want the postfix smtp client to use STARTTLS when it's offered by remote smtp servers for outgoing mail, you usually want this in main.cf: smtp_tls_security_level = may Since you are requiring submission clients to have particular client certificates, perhaps it's possible that your relay_transport host is requiring a particular client certificate from your local postfix smtp client. If so, your mistake is that, instead of getting your local postfix smtp client to use that client certificate when making connections to your relay host, you have instead tried to use it as a server certificate when submission clients connect to your local postfix smtp server. > Regards. cheers, raf
