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

Reply via email to