Discussion:
[RCU] Cannot send mail via round cube
ɹןʇnqן
2018-03-01 16:39:08 UTC
Permalink
Mar 1 09:27:02 mail submit-tls/smtpd[86118]: connect from localhost[127.0.0.1]
Mar 1 09:27:02 mail submit-tls/smtpd[86118]: SSL_accept error from localhost[127.0.0.1]: 0
Mar 1 09:27:02 mail submit-tls/smtpd[86118]: warning: TLS library problem: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:/usr/src/crypto/openssl/ssl/s3_pkt.c:1493:SSL alert number 48:
Mar 1 09:27:02 mail submit-tls/smtpd[86118]: lost connection after STARTTLS from localhost[127.0.0.1]
Mar 1 09:27:02 mail submit-tls/smtpd[86118]: disconnect from localhost[127.0.0.1] ehlo=1 starttls=0/1 commands=1/2

Sending mail on the submission port outside of roundcube works fine.

Mar 1 09:35:35 mail submit-tls/smtpd[26307]: connect from unknown[24.71.178.2]
Mar 1 09:35:36 mail submit-tls/smtpd[26307]: Anonymous TLS connection established from unknown[24.71.178.2]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Mar 1 09:35:36 mail submit-tls/smtpd[26307]: NOQUEUE: permit: RCPT from unknown[24.71.178.2]: action=permit_sasl_authenticated for Client host=unknown[24.71.178.2] ; from=<***@covisp.net> to=<***@example.net> proto=ESMTP helo=<[10.0.2.45]>
Mar 1 09:35:36 mail last message repeated 2 times
Mar 1 09:35:36 mail submit-tls/smtpd[26307]: 3zsdMr46Q6zbRf3: client=unknown[24.71.178.2], sasl_method=PLAIN, sasl_username=lbutler
--
L Butler
303 219 0564
NederHost/Sebastiaan Hoogeveen
2018-03-01 17:21:43 UTC
Permalink
Hi,
Post by ɹןʇnqן
Mar 1 09:27:02 mail submit-tls/smtpd[86118]: connect from localhost[127.0.0.1]
Mar 1 09:27:02 mail submit-tls/smtpd[86118]: SSL_accept error from localhost[127.0.0.1]: 0
Mar 1 09:27:02 mail submit-tls/smtpd[86118]: lost connection after STARTTLS from localhost[127.0.0.1]
Mar 1 09:27:02 mail submit-tls/smtpd[86118]: disconnect from localhost[127.0.0.1] ehlo=1 starttls=0/1 commands=1/2
The 'SSL alert number 48' indicates that the server certificate cannot be verified due to being issued by an unknown CA. This is probably caused by a missing, outdated or improperly configured CA bundle on the machine running Roundcube. You should be able to reproduce the problem with openssl s_client from that machine.

Kind regards,
--
Sebastiaan Hoogeveen

NederHost
https://www.nederhost.nl/
KvK: 34099781
ɹןʇnqן
2018-03-01 18:49:31 UTC
Permalink
Post by NederHost/Sebastiaan Hoogeveen
The 'SSL alert number 48' indicates that the server certificate cannot be verified due to being issued by an unknown CA. This is probably caused by a missing, outdated or improperly configured CA bundle on the machine running Roundcube. You should be able to reproduce the problem with openssl s_client from that machine.
It appears that roundcube doesn't like Let's Encrypt in a way that neither dovecot nor postfix (nor any of several MUAs) have an issue with
--
L Butler
303 219 0564
Maarten
2018-03-01 19:01:47 UTC
Permalink
I'm using letsencrypt certificates with roundcube and I'm not having any
issues.
Post by ɹןʇnqן
Post by NederHost/Sebastiaan Hoogeveen
The 'SSL alert number 48' indicates that the server certificate cannot be verified due to being issued by an unknown CA. This is probably caused by a missing, outdated or improperly configured CA bundle on the machine running Roundcube. You should be able to reproduce the problem with openssl s_client from that machine.
It appears that roundcube doesn't like Let's Encrypt in a way that neither dovecot nor postfix (nor any of several MUAs) have an issue with
Vincent Van Houtte
2018-03-01 20:48:38 UTC
Permalink
I second that.

Verzonden vanaf mijn Sony Xperia™-smartphone

---- Maarten schreef ----
Post by Maarten
I'm using letsencrypt certificates with roundcube and I'm not having any
issues.
Post by ɹןʇnqן
Post by NederHost/Sebastiaan Hoogeveen
The 'SSL alert number 48' indicates that the server certificate cannot be verified due to being issued by an unknown CA. This is probably caused by a missing, outdated or improperly configured CA bundle on the machine running Roundcube. You should be able to reproduce the problem with openssl s_client from that machine.
It appears that roundcube doesn't like Let's Encrypt in a way that neither dovecot nor postfix (nor any of several MUAs) have an issue with
_______________________________________________
Roundcube Users mailing list
http://lists.roundcube.net/mailman/listinfo/users
barul
2018-03-02 03:57:00 UTC
Permalink
Same here, been using LE certs for months without any issue.

---
barul
Post by Vincent Van Houtte
I second that.
Verzonden vanaf mijn Sony Xperia™-smartphone
---- Maarten schreef ----
Post by Maarten
I'm using letsencrypt certificates with roundcube and I'm not having any
issues.
On Mar 1, 2018, at 09:21, NederHost/Sebastiaan Hoogeveen
Post by NederHost/Sebastiaan Hoogeveen
The 'SSL alert number 48' indicates that the server certificate
cannot be verified due to being issued by an unknown CA. This is
probably caused by a missing, outdated or improperly configured CA
bundle on the machine running Roundcube. You should be able to
reproduce the problem with openssl s_client from that machine.
It appears that roundcube doesn't like Let's Encrypt in a way that
neither dovecot nor postfix (nor any of several MUAs) have an issue
with
_______________________________________________
Roundcube Users mailing list
http://lists.roundcube.net/mailman/listinfo/users
_______________________________________________
Roundcube Users mailing list
http://lists.roundcube.net/mailman/listinfo/users
ɹןʇnqן
2018-03-02 18:51:29 UTC
Permalink
How do you have it setup?

In dovecot I have the key and cert set to point to /usr/local/etc/dehydrated/certs/domain/privkey.pem and .../fullchain.pem
Post by Maarten
I'm using letsencrypt certificates with roundcube and I'm not having any
issues.
Maarten
2018-03-02 19:09:28 UTC
Permalink
ssl_cert = </etc/letsencrypt/live/webmail.feedmebits.nl/fullchain.pem
ssl_key = </etc/letsencrypt/live/webmail.feedmebits.nl/privkey.pem
Post by ɹןʇnqן
How do you have it setup?
In dovecot I have the key and cert set to point to /usr/local/etc/dehydrated/certs/domain/privkey.pem and .../fullchain.pem
Post by Maarten
I'm using letsencrypt certificates with roundcube and I'm not having any
issues.
_______________________________________________
Roundcube Users mailing list
http://lists.roundcube.net/mailman/listinfo/users
Maarten
2018-03-02 19:20:53 UTC
Permalink
In my roundcube I have the following set:

$config['imap_conn_options'] = array(
'ssl' => array(
'verify_peer' => true,
'verify_depth' => 3,
'cafile' => '/etc/pki/tls/certs/combined.pem',
),
);

Combined being ca-bundle.trust.crt and ca-bundle.crt. When I remove that
config setting I can still send mail via roundcube.
Might be worth trying seeing what it does for you.
Post by Maarten
ssl_cert = </etc/letsencrypt/live/webmail.feedmebits.nl/fullchain.pem
ssl_key = </etc/letsencrypt/live/webmail.feedmebits.nl/privkey.pem
Post by ɹןʇnqן
How do you have it setup?
In dovecot I have the key and cert set to point to
/usr/local/etc/dehydrated/certs/domain/privkey.pem and
.../fullchain.pem
Post by Maarten
I'm using letsencrypt certificates with roundcube and I'm not having any
issues.
_______________________________________________
Roundcube Users mailing list
http://lists.roundcube.net/mailman/listinfo/users
_______________________________________________
Roundcube Users mailing list
http://lists.roundcube.net/mailman/listinfo/users
Maarten
2018-03-02 19:22:40 UTC
Permalink
Or you could try setting verify_peer => false
Post by Maarten
$config['imap_conn_options'] = array(
  'ssl'         => array(
     'verify_peer'  => true,
     'verify_depth' => 3,
     'cafile'       => '/etc/pki/tls/certs/combined.pem',
   ),
 );
Combined being ca-bundle.trust.crt and ca-bundle.crt. When I remove
that config setting I can still send mail via roundcube.
Might be worth trying seeing what it does for you.
Post by Maarten
ssl_cert = </etc/letsencrypt/live/webmail.feedmebits.nl/fullchain.pem
ssl_key = </etc/letsencrypt/live/webmail.feedmebits.nl/privkey.pem
Post by ɹןʇnqן
How do you have it setup?
In dovecot I have the key and cert  set to point to
/usr/local/etc/dehydrated/certs/domain/privkey.pem and
.../fullchain.pem
Post by Maarten
I'm using letsencrypt certificates with roundcube and I'm not having any
issues.
_______________________________________________
Roundcube Users mailing list
http://lists.roundcube.net/mailman/listinfo/users
_______________________________________________
Roundcube Users mailing list
http://lists.roundcube.net/mailman/listinfo/users
Maarten
2018-03-02 19:28:22 UTC
Permalink
https://secure.php.net/manual/en/context.ssl.php
Post by Maarten
Or you could try setting verify_peer => false
Post by Maarten
$config['imap_conn_options'] = array(
  'ssl'         => array(
     'verify_peer'  => true,
     'verify_depth' => 3,
     'cafile'       => '/etc/pki/tls/certs/combined.pem',
   ),
 );
Combined being ca-bundle.trust.crt and ca-bundle.crt. When I remove
that config setting I can still send mail via roundcube.
Might be worth trying seeing what it does for you.
Post by Maarten
ssl_cert = </etc/letsencrypt/live/webmail.feedmebits.nl/fullchain.pem
ssl_key = </etc/letsencrypt/live/webmail.feedmebits.nl/privkey.pem
Post by ɹןʇnqן
How do you have it setup?
In dovecot I have the key and cert  set to point to
/usr/local/etc/dehydrated/certs/domain/privkey.pem and
.../fullchain.pem
Post by Maarten
I'm using letsencrypt certificates with roundcube and I'm not having any
issues.
_______________________________________________
Roundcube Users mailing list
http://lists.roundcube.net/mailman/listinfo/users
_______________________________________________
Roundcube Users mailing list
http://lists.roundcube.net/mailman/listinfo/users
_______________________________________________
Roundcube Users mailing list
http://lists.roundcube.net/mailman/listinfo/users
Maarten
2018-03-02 19:36:21 UTC
Permalink
verify_peer was added in php 5.6.0 so if you are running a lower version
that option won't work.
Post by Maarten
https://secure.php.net/manual/en/context.ssl.php
Post by Maarten
Or you could try setting verify_peer => false
Post by Maarten
$config['imap_conn_options'] = array(
  'ssl'         => array(
     'verify_peer'  => true,
     'verify_depth' => 3,
     'cafile'       => '/etc/pki/tls/certs/combined.pem',
   ),
 );
Combined being ca-bundle.trust.crt and ca-bundle.crt. When I remove
that config setting I can still send mail via roundcube.
Might be worth trying seeing what it does for you.
Post by Maarten
ssl_cert = </etc/letsencrypt/live/webmail.feedmebits.nl/fullchain.pem
ssl_key = </etc/letsencrypt/live/webmail.feedmebits.nl/privkey.pem
Post by ɹןʇnqן
How do you have it setup?
In dovecot I have the key and cert  set to point to
/usr/local/etc/dehydrated/certs/domain/privkey.pem and
.../fullchain.pem
Post by Maarten
I'm using letsencrypt certificates with roundcube and I'm not having any
issues.
_______________________________________________
Roundcube Users mailing list
http://lists.roundcube.net/mailman/listinfo/users
_______________________________________________
Roundcube Users mailing list
http://lists.roundcube.net/mailman/listinfo/users
_______________________________________________
Roundcube Users mailing list
http://lists.roundcube.net/mailman/listinfo/users
_______________________________________________
Roundcube Users mailing list
http://lists.roundcube.net/mailman/listinfo/users
LuKreme
2018-03-02 23:04:32 UTC
Permalink
I have much the same, only with a path pointing to the fullchain.pem file from LE. I suspect it is not readable by the http server, so how are you getting that /etc/Ppi file generated, since it is not the same path as you show in dovecot?

I tried linking to the fullchain.pem, but I haven't tried making a local copy for Roundcube yet.

The paths to the certs work fine for https via Apache.
--
My main job is trying to come up with new and innovative and effective ways to reject even more mail. I'm up to about 97% now.
Post by Maarten
$config['imap_conn_options'] = array(
'ssl' => array(
'verify_peer' => true,
'verify_depth' => 3,
'cafile' => '/etc/pki/tls/certs/combined.pem',
),
);
Maarten
2018-03-03 09:08:42 UTC
Permalink
The file you are asking about as /etc/Ppi? That file is the roundcube
configuration file--> config.inc.php:

// IMAP socket context options
// See http://php.net/manual/en/context.ssl.php
// The example below enables server certificate validation
$config['imap_conn_options'] = array(
  'ssl'         => array(
     'verify_peer'  => true,
     'verify_depth' => 3,
     'cafile'       => '/etc/pki/tls/certs/combined.pem',
   ),
 );

If I understand ssl correctly I don't see the point to putting
fullchain.pem letsencrypt there, because of the following. Your browser
has the Root certificates installed, a php application does not. So when

you go to a webpage using letsencrypt certificates . You will see
something like this:

DST Root CA X2  --> Root Certificate in browser

   Let's encrypt Authority X3 -->

        webmail.yourdomain.com --> your certificate


So the web browser uses the Root Certificate to verify the chain  of
certificates to be valid. As far as I know a php application has no way
knowing if the service it's connecting to is using a valid ssl chain, I
don't know enough about php to be sure about this but sounds correct. If
I am wrong about this someone may correct me about this and explain it
to me how this works in php. In the case of roundcube connection to an
imap server or smtp server:

$config['default_host'] = 'ssl://imap.%d';

$config['smtp_server'] = 'tls://smtp.%d';

You have said you have the location of your cafile pointing to the
fullchain letsencrypt file, it may see it as valid but as far as I know
the Root certificates should be used in using to validate the chain.
Which are defined in the ca bundles that come with the OS. That's why I
have fullchain in my dovecot configuration and
combined.pem(ca-bundle.trust.crt and ca-bundle.crt) file in my roundcube
configuration, since roundcube can validate that way if the chain of the
imap server is valid.

The way you have it works for Apache because Apache is the server, and
the client being a web-browser checks the chain via the Root
certificates in the browser. In case of roundcube connecting to an imap
or smtp server, roundcube is acting as a client to the smtp and imap
server and has to validate the certificates it's receiving from them via
the Root Certificates and the fullchain.pem. So in short if you are the
server you have to have the full chain so that a client can validate the
server's certificate via the Root Certificates, which are installed in
the browsers, and in cabundles on the OS, and I think java uses keystore
to store certificate chains, Root certificates, etc.
Post by LuKreme
I have much the same, only with a path pointing to the fullchain.pem file from LE. I suspect it is not readable by the http server, so how are you getting that /etc/Ppi file generated, since it is not the same path as you show in dovecot?
I tried linking to the fullchain.pem, but I haven't tried making a local copy for Roundcube yet.
The paths to the certs work fine for https via Apache.
Maarten
2018-03-03 11:59:02 UTC
Permalink
When roundcube connects to an imap or smtp server it's being a client
therefore I think it would be logical that the client needs to validate
the chain. When you are connecting to roundcube webinterface you are
connecting to the server serving it, in that setting the browser is the
client and the apache/nginx being the server. It's all a matter of who
is the client and who is the server perspective as in who needs to
validate and who needs to show they have a valid chain.
Post by Maarten
If I understand ssl correctly I don't see the point to putting
fullchain.pem letsencrypt there, because of the following. Your browser
has the Root certificates installed, a php application does not. So when
you go to a webpage using letsencrypt certificates . You will see
DST Root CA X2  --> Root Certificate in browser
    Let's encrypt Authority X3 -->
         webmail.yourdomain.com --> your certificate
So the web browser uses the Root Certificate to verify the chain  of
certificates to be valid. As far as I know a php application has no way
knowing if the service it's connecting to is using a valid ssl chain, I
don't know enough about php to be sure about this but sounds
correct. If
I am wrong about this someone may correct me about this and explain it
to me how this works in php.
exactly the same way as on the browser side
no idea why you think PHP is special here
"As far as I know a php application has no way knowing if the service
it's connecting to is using a valid ssl chain" is pure bullshit - get
a proper maintained operating system and you have all working
out-of-the-box
http://php.net/manual/en/migration56.openssl.php
All encrypted client streams now enable peer verification by default.
By default, this will use OpenSSL's default CA bundle to verify the
peer certificate. In most cases, no changes will need to be made to
communicate with servers with valid SSL certificates, as distributors
generally configure OpenSSL to use known good CA bundles
it's using even the same ca-bundle than everything else on the system,
the ca-bundle from mozilla - frankly do you think the php-devleopers
are idiots and enable verification by default when it won't work on
any reasonable server?
openssl-libs-1.1.0g-1.fc27.x86_64
openssl-libs              /etc/pki/tls
openssl-libs              /etc/pki/tls/certs
openssl-libs              /etc/pki/tls/misc
openssl-libs              /etc/pki/tls/openssl.cnf
openssl-libs              /etc/pki/tls/private
....
total 4.0K
-rw-r--r-- 1 root root 2.5K 2017-11-06 09:24 Makefile
lrwxrwxrwx 1 root root   49 2018-02-06 14:48 ca-bundle.crt ->
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
lrwxrwxrwx 1 root root   55 2018-02-06 14:48 ca-bundle.trust.crt ->
/etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
ca-certificates-2018.2.22-1.0.fc27.noarch
ca-certificates-2018.2.22-1.0.fc27.noarch
Name        : ca-certificates
Version     : 2018.2.22
Release     : 1.0.fc27
Architecture: noarch
Install Date: Thu Feb  8 09:43:10 2018
Group       : System Environment/Base
Size        : 974873
License     : Public Domain
Signature   : RSA/SHA256, Tue Feb  6 14:57:19 2018, Key ID
f55e7430f5282ee4
Source RPM  : ca-certificates-2018.2.22-1.0.fc27.src.rpm
Build Date  : Tue Feb  6 14:48:33 2018
Build Host  : buildvm-ppc64le-04.ppc.fedoraproject.org
Relocations : (not relocatable)
Packager    : Fedora Project
Vendor      : Fedora Project
URL         : https://fedoraproject.org/wiki/CA-Certificates
Summary     : The Mozilla CA root certificate bundle
This package contains the set of CA certificates chos
ɹןʇnqן,
2018-03-03 13:03:14 UTC
Permalink
Sorry for the typo. I meant the actual pen file pointed at in the path. (The one I currently set to t the LE fullchain in hopes it would work).

I think I understand now that roundcube wants the root certs (though I thought fullchain specifically included everything needed from root to local cert, thus the name).

It was previously set to, IIRC, /etc/ssl/certs/something... but that wasn’t working either. I’ll double check that path and see what it looks like it should be and go from there. Maybe even figure out why it stopped working?
Post by Maarten
'cafile' => '/etc/pki/tls/certs/combined.pem',
Im on an iPhone and out of the country, so ssh in is a special kind of phun! 😉

Thanks a lot for your replies, they are certainly helpful.
--
This is my signature. There are many like it, but this one is mine.
ɹןʇnqן
2018-03-03 13:50:50 UTC
Permalink
Post by ɹןʇnqן,
It was previously set to, IIRC, /etc/ssl/certs/something
Close. It was set (and is again set to) /etc/ssl/cert.pem which is a link to /usr/local/share/certs/ca-root-nss.crt which contains 151 certs.

$config['imap_conn_options'] = array(
'ssl' => array(
'verify_peer' => true,
'verify_depth' => 3,
'cafile' => '/etc/ssl/cert.pem',
),
);

Same error.

The only thing that seems to work is setting it up to not verify at all which seems less than ideal.
Loading...