That is an intriguing error.

SNI adoption has been very slow for email. Dovecot supports it for POP3/IMAP clients. Opensmtpd may be the only SMTP server which supports it.

The workaround SMTP behavior has been to look up the MX record of the "To:" domain, and then connect to THAT server and verify ITS certificate. So contrary to HTTP where the verified certificate MUST match the requested domain name, mail only requires that the certificate match the server pointed to by the MX record (regardless of message's "To:" domain).

So in general, "SNI" does not come up in discussions of mail server certificates.

And thus your error message is quite intriguing.

Can you modify the perl script to output verbose information?


On 7/23/2019 5:04 AM, Angus McIntyre wrote: 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:


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:


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 ( doesn't match the name on the certificate.

Things I'm going to try:

   1. Adding '' to /etc/hosts
   2. Using a self-signed certificate signed to ''.
   3. Buying another certificate specifically for ''

Sound reasonable?


Il giorno 22 lug 2019, alle ore 19:41, Eric's mail <> ha scritto:


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 ( 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.


Get Outlook for Android <>
* 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" < <>> wrote: 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: s6

    (obviously, 'mydomain' is not the actual name here). The .pem file
    contains the lines:

        Subject: OU=Domain Control Validated, OU=PositiveSSL,


        X509v3 Subject Alternative Name:

    '' and '' all resolve to the same IP.

    My existing qmailtoaster server (running an older version of the
    software) has '/etc/hosts' containing: s2

    and the .pem file contains:

        Subject: OU=Domain Control Validated, OU=PositiveSSL Multi-Domain,


        X509v3 Subject Alternative Name:

    '' resolves to the same IP as '';
    '' resolves to the same IP as ''.

    As far as I can see, the two situations are equivalent, with the slight
    difference that the official server name of the new box
    ('') is not a subdomain of the domain in the PEM file
    (''), whereas on the old box the name of the host
    ('') is a subdomain of one of the domain names in the PEM     file (''). I don't know if this is a possible cause of my

    One other difference is that I don’t have a PTR record for
    ''. An RDNS lookup on the IP of '' will
    yield '', but an RDNS lookup on the IP of
    '' 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.



    >     >> 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 After installation, I patched the Squirrelmail
    config and the smtps supervise as directed at: >> >> >> >> 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
    >> 2019-07-22 02:45:15.179905500 tcpserver: ok 2843
    s6: >> : >> 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/' so that it contains: >> >>
    $config['smtp_server'] = 'tls://'; >> >>
    $config['smtp_conn_options'] = array( >> 'ssl' => array( >>
    'peer_name' => '', >> 'verify_peer' => true, >>
    'verify_depth' => 3, >> 'cafile' =>
    '/var/qmail/control/servercert.pem', >> ), >> ); >> >> (where
    '' 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:// >>
    [21-Jul-2019 22:26:08 -0400]: Recv: 220 - >> Welcome
    to Qmail Toaster Ver. 1.03-2.1.qt.el7 SMTP Server ESMTP >>
    [21-Jul-2019 22:26:08 -0400]: Send: EHLO >>
    [21-Jul-2019 22:26:08 -0400]: Recv: - >> 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: >> For additional
    commands, e-mail: >>
    To unsubscribe, e-mail: For additional
    commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to