Remo, I don't think the order matters in tlsserverciphers. I cat'd the cert, the key, and the chain into my file, in that order, and it works fine.
Nice bug catch on the cipher list. I made the script on the latest centos-7 toaster which installs with a cipher list of "DH:!LOW:!MEDIUM" in tcp.smtp. The sed command merely replaces it. If it's not present, or different, nothing happens (i.e. it fails gracefully). It did not seem to affect your connection, as that was just a cert verify problem. Do you have a TLSCIPHERS environ. variable in tcp.smtp? In my file, the line for remote mail ends with: TLSCIPHERS="ECDHE:DHE:ECDH:DH:AES:!SSLv2!SSLv3" I just checked a centos-5 installation, and there is no TLSCIPHERS variable in tcp.smtp. I just connected to that machine with s_client and it established a TLSv1.0 connection, so apparently there is a default cipher list present in qmail-smtpd (I confirmed that port 587 does not go through spamdyke). Specifying ciphers is merely due to my over paranoia. 99.999% of people will likely be happy with the defaults. -Andy On 8/13/2018 9:25 PM, Remo Mattei wrote: > I think I need to add the intermediary cert. looks like.. trying to > figure that out now.. not sure which order they go. > > Andrew Swartz wrote on 8/13/18 22:24: >> Remo, >> >> I just did this: >> >> openssl s_client -starttls smtp -crlf -connect qmail.rm.ht:587 >> >> and got the same result. >> >> Therefore you've probably had this problem for a while. >> >> Are you using the cert with the "full chain"? Apparently bare certs >> rarely verify, and I've read several recommendations to provide the >> server with the pem file containing the full chain. >> >> If you read the stuff at the "STARTTLS Everywhere" site, they state that >> most mail servers to not require (or even attempt) cert verification, >> and changing this is one of their goals. >> >> -Andy >> >> >> >> On 8/13/2018 8:56 PM, Remo Mattei wrote: >>> Any suggestions on this Andy? >>> >>> openssl s_client -crlf -connect qmail.rm.ht:465 >>> CONNECTED(00000005) >>> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht >>> verify error:num=20:unable to get local issuer certificate >>> verify return:1 >>> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht >>> verify error:num=27:certificate not trusted >>> verify return:1 >>> depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = qmail.rm.ht >>> verify error:num=21:unable to verify the first certificate >>> verify return:1 >>> --- >>> Certificate chain >>> 0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=qmail.rm.ht >>> i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO >>> RSA Domain Validation Secure Server CA >>> --- >>> >>> >>> I do have a valid cert as you can see it’s from COMODO. But not sure >>> about the first few lines >>> >>> Remo >>> >>>> On Aug 13, 2018, at 21:42, Andrew Swartz <awswa...@acsalaska.net >>>> <mailto:awswa...@acsalaska.net>> wrote: >>>> >>>> I just realized that the plain text line-wrapped the script, so here >>>> is an unwrapped version in case anyone else wants to use it. Also, I >>>> made it multiline so you can cut and paste it into a terminal and >>>> accomplish this in about 3 seconds with netstat confirming success (it >>>> should print a single line showing tcpserver listening on 465). >>>> >>>> rfc8314 <https://tools.ietf.org/html/rfc8314> in Jan of this year >>>> reinstates port 465/tls because starttls (port 587) is broken beyond >>>> repair (from a security perspective). So eventually everyone may >>>> eventually need to go back to port 465. But since servers get to >>>> dictate setting to their clients without creating interoperability >>>> issues, it will likely be many years before this occurs. >>>> >>>> The critical flaw in starttls is that some ISP's and/or governments >>>> have been caught filtering out the STARTTLS packet and thus preventing >>>> the initiation of encryption (a "starttls downgrade attack"). In that >>>> case, the client's username and password are sent in the clear. And >>>> if an eavesdropper gets those, they can wreak havoc on your your life >>>> (i.e. by resetting the password for your bank or other online >>>> accounts, etc). With port 465/tls, the client connection either >>>> establishes encryption or fails; it cannot be tricked into using >>>> clear-text. >>>> >>>> Anyway, here is the paste-able script: >>>> >>>> qmailctl stop; \ >>>> cp -r /var/qmail/supervise/submission /var/qmail/supervise/smtps; \ >>>> chown -R qmaill:qmail /var/qmail/supervise/smtps; \ >>>> sed -i 's/REQUIRE_AUTH=1/REQUIRE_AUTH=1\nexport SMTPS=1/' >>>> /var/qmail/supervise/smtps/run; \ >>>> sed -i 's/587/465/' /var/qmail/supervise/smtps/run; \ >>>> sed -i 's/submission/smtps/' /var/qmail/supervise/smtps/log/run; \ >>>> sed -i 's/DH:!LOW:!MEDIUM/ECDHE:DHE:ECDH:DH:AES:!SSLv2:!SSLv3/' >>>> /etc/tcprules.d/tcp.smtp; \ >>>> qmailctl cdb; \ >>>> qmailctl start; \ >>>> netstat -lnp | grep 465 >>>> >>>> >>>> -Andy >>>> >>>> PS: If old clients cannot connect, then remove the "!SSLv3" from the >>>> cipher list in tcp.smtp >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 8/13/2018 7:32 PM, Remo Mattei wrote: >>>>> Cool! I remember I did it like Eric described but the bottom line is >>>>> it works either way. I do not offer 465 any longer :) >>>>> >>>>> *dal mio iPhone X* >>>>> >>>>> Il giorno 13 ago 2018, alle ore 20:25, Andrew Swartz >>>>> <awswa...@acsalaska.net <mailto:awswa...@acsalaska.net>> ha scritto: >>>>> >>>>>> I eventually figured this out, and accomplished the same result though I >>>>>> went about it slightly differently. It is now fully functional. Below >>>>>> is the script which I created and accomplishes this in very few lines. >>>>>> It copies the supervise/smtp directory to supervise/smtps and it then >>>>>> edits a few values in two files files (plus editing the cipher list in >>>>>> tcp.smtp). >>>>>> >>>>>> >>>>>> qmailctl stop >>>>>> cp -r /var/qmail/supervise/submission /var/qmail/supervise/smtps >>>>>> chown -R qmaill:qmail /var/qmail/supervise/smtps >>>>>> sed -i 's/REQUIRE_AUTH=1/REQUIRE_AUTH=1\nexport SMTPS=1/' >>>>>> /var/qmail/supervise/smtps/run >>>>>> sed -i 's/587/465/' /var/qmail/supervise/smtps/run >>>>>> sed -i 's/submission/smtps/' /var/qmail/supervise/smtps/log/run >>>>>> sed -i 's/DH:!LOW:!MEDIUM/ECDHE:DHE:ECDH:DH:AES:!SSLv2/' >>>>>> /etc/tcprules.d/tcp.smtp >>>>>> qmailctl cdb >>>>>> qmailctl start >>>>>> >>>>>> >>>>>> Thanks for confirming that I did it right, >>>>>> Andy >>>>>> >>>>>> >>>>>> On 8/13/2018 7:06 PM, Eric Broch wrote: >>>>>>> Stock CentOS 7 does not have SMTPS standard. You must create the >>>>>>> supervise scripts. >>>>>>> >>>>>>> You could stop qmail >>>>>>> >>>>>>> # qmailctl stop >>>>>>> >>>>>>> and copy smtp supervise scripts to smtps (make sure qmail is stopped or >>>>>>> else you'll have a mess): >>>>>>> >>>>>>> # cp -Rp /var/qmail/supervise/smtp /var/qmail/supervise/smtps >>>>>>> >>>>>>> Then change two files: >>>>>>> >>>>>>> /var/qmail/supervise/smtps/run >>>>>>> >>>>>>> <run> >>>>>>> >>>>>>> #!/bin/sh >>>>>>> QMAILDUID=`id -u vpopmail` >>>>>>> NOFILESGID=`id -g vpopmail` >>>>>>> MAXSMTPD=`cat /var/qmail/control/concurrencyincoming` >>>>>>> SMTPD="/var/qmail/bin/qmail-smtpd" >>>>>>> TCP_CDB="/etc/tcprules.d/tcp.smtp.cdb" >>>>>>> HOSTNAME=`hostname` >>>>>>> VCHKPW="/home/vpopmail/bin/vchkpw" >>>>>>> export SMTPS=1 >>>>>>> >>>>>>> exec /usr/bin/softlimit -m 128000000 \ >>>>>>> /usr/bin/tcpserver -v -R -H -l $HOSTNAME -x $TCP_CDB -c >>>>>>> "$MAXSMTPD" \ >>>>>>> -u "$QMAILDUID" -g "$NOFILESGID" 0 465 \ >>>>>>> $SMTPD $VCHKPW /bin/true 2>&1 >>>>>>> >>>>>>> </run> >>>>>>> >>>>>>> & >>>>>>> >>>>>>> /var/qmail/supervise/smtps/log/run >>>>>>> >>>>>>> <run> >>>>>>> >>>>>>> #!/bin/sh >>>>>>> LOGSIZE=`cat /var/qmail/control/logsize` >>>>>>> LOGCOUNT=`cat /var/qmail/control/logcount` >>>>>>> exec /usr/bin/setuidgid qmaill /usr/bin/multilog \ >>>>>>> t s$LOGSIZE n$LOGCOUNT /var/log/qmail/smtps 2>&1 >>>>>>> >>>>>>> </run> >>>>>>> >>>>>>> Start qmail (# qmailctl start) >>>>>>> >>>>>>> >>>>>>> On 8/11/2018 6:36 PM, Andrew Swartz wrote: >>>>>>>> I just installed qmailtoaster onto CentOS-7. The qt_install script >>>>>>>> opened port 465 on the firewall. However, s_client cannot connect to >>>>>>>> port 465 and netstat shows that nothing is listening on port 465. >>>>>>>> >>>>>>>> Can anyone point me at appropriate instructions for setting up >>>>>>>> listening >>>>>>>> on port 465 which are specific (or applicable) to qmailtoaster? I >>>>>>>> searched wiki.qmailtoaster.com <http://wiki.qmailtoaster.com/> and >>>>>>>> found nothing. I did some general >>>>>>>> googling and found several somewhat conflicting descriptions but I'm >>>>>>>> unsure which apply to the configuration used in qmailtoaster. >>>>>>>> >>>>>>>> My interest is because 465 has been reinstated (in Jan 2018) as the >>>>>>>> preferred submission port due to security problems with STARTTLS >>>>>>>> (https://tools.ietf.org/html/rfc8314). >>>>>>>> >>>>>>>> Thanks, >>>>>>>> -Andy >>>>>>>> >>>>>>>> >>>>>> -- >>>>>> Andrew W. Swartz, MD >>>>>> Departments of Emergency Medicine, Family Medicine, and Surgery >>>>>> Yukon-Kuskokwim Delta Regional Hospital >>>>>> Bethel, Alaska >>>>>> >>>> -- >>>> Andrew W. Swartz, MD >>>> Departments of Emergency Medicine, Family Medicine, and Surgery >>>> Yukon-Kuskokwim Delta Regional Hospital >>>> Bethel, Alaska > > -- > Sent from Postbox <https://www.postbox-inc.com> -- Andrew W. Swartz, MD Departments of Emergency Medicine, Family Medicine, and Surgery Yukon-Kuskokwim Delta Regional Hospital Bethel, Alaska
smime.p7s
Description: S/MIME Cryptographic Signature
