You do not have to buy a new cert use let’s encrypt or self sign it works just fine.
> Il giorno 23 lug 2019, alle ore 06:04, Angus McIntyre <an...@pobox.com> ha > scritto: > > r...@mattei.org wrote on 7/22/19 11:06 PM: > > I am not sure why you keep having all this issues. Let me > > know off line maybe I can take a look. > > Thanks, Remo. I think I may be getting closer to a fix. > > The issues I was having with PHP/Roundcube installation turned out to be > because I had the IUS repo enabled, and that was introducing conflicts. I've > now managed to work past that. > > My new problems look like a certificate issue, and I think the problem is > that my certificate requires SNI. > > If I run: > > perl analyze-ssl.pl mail.mydomain.dev:465 > > I get: > > * SNI supported : certificate verify fails without SNI > * certificate verified : FAIL: SSL connect attempt failed > error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed > > whereas if I do: > > perl analyze-ssl.pl mail.mydomain.dev:443 > > I get: > > * SNI supported : ok > * certificate verified : ok > > I'm using the same certificate for securing the webserver (port 443) and > SMTPS (port 465). The webserver works fine, probably because Apache is > passing the requested hostname to Server Name Indication; SMTPS fails with a > certificate error, probably because there's no hostname passed to SNI, and > the server's intrinsic hostname (s6.mydomain.com) doesn't match the name on > the certificate. > > Things I'm going to try: > > 1. Adding 'mail.mydomain.dev' to /etc/hosts > 2. Using a self-signed certificate signed to 's6.mydomain.com'. > 3. Buying another certificate specifically for 's6.mydomain.com' > > Sound reasonable? > > Angus > > > >>>> Il giorno 22 lug 2019, alle ore 19:41, Eric's mail >>>> <ebr...@whitehorsetc.com> ha scritto: >>> >>> >>> Angus, >>> >>> Did you think about simply using port 25, no authentication or encryption, >>> which is how squirrelmail on QMT used to be configured, relying on HTTPS >>> alone for password and email security across the cloud as the email (after >>> the cloud) is submitted directly to the server (tcpserver) by the server >>> (apache) itself (127.0.0.1) rendering encryption useless or redundant. I >>> think this is the route I will go because with every upgrade of roundcube, >>> the webmail I prefer, there seems to be issues with past configurations. >>> >>> Eric >>> >>> Get Outlook for Android <https://aka.ms/ghei36> >>> * SNI supported : certificate verify fails without SNI > * certificate verified : FAIL: SSL connect attempt failed error:14007086:SSL > routines:CONNECT_CR_CERT:certificate verify failed >>> >>> >>> >>>> On Mon, Jul 22, 2019 at 5:46 PM -0600, "Angus McIntyre" <an...@pobox.com >>>> <mailto:an...@pobox.com>> wrote: >>> >>> r...@mattei.org wrote on 7/22/19 10:22 AM: >>> > You need to install the cert on your machine. Does the /etc/hosts >>> > have the name of your machine can you try to ping that name to >>> > see if it resolves? >>> >>> The certificate is installed. >>> >>> The hostname in '/etc/hosts' resolves, and responds to pings. >>> >>> >>> I replaced the self-signed PEM that shipped with qmailtoaster with one >>> that I made myself by concatenating the ‘.key’ and ‘.crt’ files from my >>> server certificate. Inspecting the resulting .pem with ‘openssl x509 -in >>> servercert.pem -text’ confirms that the resulting .pem is for the domain >>> that I expect. File permissions and ownership are correct. >>> >>> '/etc/hosts' for my newly-built server contains the following line: >>> >>> 127.0.1.1 s6.mydomain.com s6 >>> >>> (obviously, 'mydomain' is not the actual name here). The .pem file >>> contains the lines: >>> >>> Subject: OU=Domain Control Validated, OU=PositiveSSL, >>> CN=mail.mydomain.dev >>> >>> and >>> >>> X509v3 Subject Alternative Name: >>> DNS:mail.mydomain.dev, DNS:www.mail.mydomain.dev >>> >>> 's6.mydomain.com' and 'mail.mydomain.dev' all resolve to the same IP. >>> >>> My existing qmailtoaster server (running an older version of the >>> software) has '/etc/hosts' containing: >>> >>> 127.0.1.1 s2.mydomain.com s2 >>> >>> and the .pem file contains: >>> >>> Subject: OU=Domain Control Validated, OU=PositiveSSL Multi-Domain, >>> CN=mydomain.com >>> >>> and >>> >>> X509v3 Subject Alternative Name: >>> DNS:mydomain.com, DNS:mail.mydomain.com, DNS:www.mydomain.com >>> >>> 's6.mydomain.com' resolves to the same IP as 'mail.mydomain.dev'; >>> 's2.mydomain.com' resolves to the same IP as 'mail.mydomain.com'. >>> >>> As far as I can see, the two situations are equivalent, with the slight >>> difference that the official server name of the new box >>> ('s6.mydomain.com') is not a subdomain of the domain in the PEM file >>> ('mail.mydomain.dev'), whereas on the old box the name of the host >>> ('s2.mydomain.com') is a subdomain of one of the domain names in the PEM >>> file ('mydomain.com'). I don't know if this is a possible cause of my >>> problems. >>> >>> One other difference is that I don’t have a PTR record for >>> 's6.mydomain.com'. An RDNS lookup on the IP of 's2.mydomain.com' will >>> yield 's2.mydomain.com', but an RDNS lookup on the IP of >>> 's6.mydomain.com' yields the FQDN of the Linode VM it runs on. Could >>> that be an issue? >>> >>> I'll keep digging on this, but if anyone has any suggestions of tests or >>> tools I might use, I'd welcome your recommendations. >>> >>> Thanks, >>> >>> Angus >>> >>> >>> >>> > >> Il giorno 21 lug 2019, alle ore 20:03, Angus McIntyre ha >>> scritto: >> >> Thanks to a great deal of help from Remi and >>> Eric, I have now managed to get my Ansible role to the point where >>> it can successfully build out a QMailToaster server running PHP >>> 7.1 and RoundCube 1.4rc1. >> >> However, because nothing is ever >>> that easy, RoundCube and SquirrelMail have now stopped sending >>> mail (RainLoop works fine). >> >> 1) SquirrelMail >> >> >>> SquirrelMail was installed from the qmailtoaster RPMs, using: >> >>> >> yum --enablerepo=qmt-testing update >> yum >>> --enablerepo=qmt-devel update >> >> as on the homepage of >>> qmailtoaster.com. After installation, I patched the Squirrelmail >>> config and the smtps supervise as directed at: >> >> >>> http://www.qmailtoaster.com/sqmailconfig.html >> >> Attempting to >>> send from SquirrelMail produces the message: >> >> 0 Can't open >>> SMTP stream >> >> The /var/log/qmail/smtps/current log shows: >> >>> >> 2019-07-22 02:45:15.173127500 tcpserver: status: 1/100 >> >>> 2019-07-22 02:45:15.179903500 tcpserver: pid 2843 from 127.0.0.1 >>> >> 2019-07-22 02:45:15.179905500 tcpserver: ok 2843 >>> s6:127.0.0.1:465 >> :127.0.0.1::58822 >> 2019-07-22 >>> 02:45:15.197381500 tcpserver: end 2843 status 256 >> 2019-07-22 >>> 02:45:15.197383500 tcpserver: status: 0/100 >> >> 2) RoundCube >> >>> >> RoundCube is 1.4rc1, installed from the remi-test repo. >>> Following Eric's instructions, I edited >>> '/etc/roundcubemail/config.inc.php' so that it contains: >> >> >>> $config['smtp_server'] = 'tls://mail.myhost.com'; >> >> >>> $config['smtp_conn_options'] = array( >> 'ssl' => array( >> >>> 'peer_name' => 'mail.myhost.com', >> 'verify_peer' => true, >> >>> 'verify_depth' => 3, >> 'cafile' => >>> '/var/qmail/control/servercert.pem', >> ), >> ); >> >> (where >>> 'mail.myhost.com' is the actual name of my mailserver, as it >>> appears in the 'servercert.pem' file). >> >> Trying to send from >>> RoundCube produces a 220 Authentication Failed message. The >>> transcript in RoundCube's SMTP log looks like: >> >> [21-Jul-2019 >>> 22:26:08 -0400]: Connecting to >> tls://mail.myhost.com:587... >> >>> [21-Jul-2019 22:26:08 -0400]: Recv: 220 s6.myhost.net - >> Welcome >>> to Qmail Toaster Ver. 1.03-2.1.qt.el7 SMTP Server ESMTP >> >>> [21-Jul-2019 22:26:08 -0400]: Send: EHLO mail.myhost.com >> >>> [21-Jul-2019 22:26:08 -0400]: Recv: 250-s6.myhost.net - >> Welcome >>> to Qmail Toaster Ver. 1.03-2.1.qt.el7 SMTP Server >> [21-Jul-2019 >>> 22:26:08 -0400]: Recv: 250-STARTTLS >> [21-Jul-2019 22:26:08 >>> -0400]: Recv: 250-PIPELINING >> [21-Jul-2019 22:26:08 -0400]: >>> Recv: 250-8BITMIME >> [21-Jul-2019 22:26:08 -0400]: Recv: 250 SIZE >>> 20971520 >> [21-Jul-2019 22:26:08 -0400]: Send: STARTTLS >> >>> [21-Jul-2019 22:26:08 -0400]: Recv: 220 ready for tls >> >>> [21-Jul-2019 22:26:08 -0400]: Send: RSET >> [21-Jul-2019 22:27:08 >>> -0400]: Send: QUIT >> [21-Jul-2019 22:27:08 -0400]: Recv: 454 TLS >>> connection >> failed: error:140760FC:SSL >>> routines:SSL23_GET_CLIENT_HELLO:unknown >> protocol (#4.3.0) >> >> >>> 3) Desktop client >> >> Trying to send from a desktop client >>> (PostBox) also fails, generating the warning: >> >> Could not >>> verify this certificate because the issuer is unknown >> >> The >>> issuer in this case is actually Sectigo, which is the new name for >>> Comodo, who should be reasonably reputable. >> >> The >>> 'servercert.pem' file that I'm using is generated from the same >>> '.key' and '.crt' files that I use to secure the webserver, which >>> appear to work fine in that context. >> >> >> >> Has anyone >>> encountered this issue, or can suggest a possible fix? >> >> >>> Thanks for any help you can give me, >> >> Angus >> >> >> >> >>> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: >>> qmailtoaster-list-unsubscr...@qmailtoaster.com >> For additional >>> commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: >>> qmailtoaster-list-unsubscr...@qmailtoaster.com For additional >>> commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com >> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com >
--------------------------------------------------------------------- To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
