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=lbutler@covisp.net to=user@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
Hi,
On 1 Mar 2018, at 17:39, ɹןʇnqן <lbutler+roundcube@covisp.net> wrote:
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
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,
On Mar 1, 2018, at 09:21, NederHost/Sebastiaan Hoogeveen s.hoogeveen@nederhost.nl wrote:
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
I'm using letsencrypt certificates with roundcube and I'm not having any issues.
On 03/01/2018 07:49 PM, ɹןʇnqן wrote:
On Mar 1, 2018, at 09:21, NederHost/Sebastiaan Hoogeveen s.hoogeveen@nederhost.nl wrote:
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
I second that.
Verzonden vanaf mijn Sony Xperia™-smartphone
---- Maarten schreef ----
I'm using letsencrypt certificates with roundcube and I'm not having any issues.
On 03/01/2018 07:49 PM, ɹןʇnqן wrote:
On Mar 1, 2018, at 09:21, NederHost/Sebastiaan Hoogeveen s.hoogeveen@nederhost.nl wrote:
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 users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
Same here, been using LE certs for months without any issue.
barul
On 2018-03-01 21:48, Vincent Van Houtte wrote:
I second that.
Verzonden vanaf mijn Sony Xperia™-smartphone
---- Maarten schreef ----
I'm using letsencrypt certificates with roundcube and I'm not having any issues.
On 03/01/2018 07:49 PM, ɹןʇnqן wrote:
On Mar 1, 2018, at 09:21, NederHost/Sebastiaan Hoogeveen s.hoogeveen@nederhost.nl wrote:
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 users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
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
On Mar 1, 2018, at 11:01, Maarten mailinglists@feedmebits.nl wrote:
I'm using letsencrypt certificates with roundcube and I'm not having any issues.
ssl_cert = </etc/letsencrypt/live/webmail.feedmebits.nl/fullchain.pem ssl_key = </etc/letsencrypt/live/webmail.feedmebits.nl/privkey.pem
On 03/02/2018 07:51 PM, ɹןʇnqן wrote:
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
On Mar 1, 2018, at 11:01, Maarten mailinglists@feedmebits.nl wrote:
I'm using letsencrypt certificates with roundcube and I'm not having any issues.
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
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.
On 2018-03-02 20:09, Maarten wrote:
ssl_cert = </etc/letsencrypt/live/webmail.feedmebits.nl/fullchain.pem ssl_key = </etc/letsencrypt/live/webmail.feedmebits.nl/privkey.pem
On 03/02/2018 07:51 PM, ɹןʇnqן wrote:
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
On Mar 1, 2018, at 11:01, Maarten mailinglists@feedmebits.nl wrote:
I'm using letsencrypt certificates with roundcube and I'm not having any issues.
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
Or you could try setting verify_peer => false
On 03/02/2018 08:20 PM, Maarten wrote:
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.
On 2018-03-02 20:09, Maarten wrote:
ssl_cert = </etc/letsencrypt/live/webmail.feedmebits.nl/fullchain.pem ssl_key = </etc/letsencrypt/live/webmail.feedmebits.nl/privkey.pem
On 03/02/2018 07:51 PM, ɹןʇnqן wrote:
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
On Mar 1, 2018, at 11:01, Maarten mailinglists@feedmebits.nl wrote:
I'm using letsencrypt certificates with roundcube and I'm not having any issues.
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
https://secure.php.net/manual/en/context.ssl.php
On 03/02/2018 08:22 PM, Maarten wrote:
Or you could try setting verify_peer => false
On 03/02/2018 08:20 PM, Maarten wrote:
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.
On 2018-03-02 20:09, Maarten wrote:
ssl_cert = </etc/letsencrypt/live/webmail.feedmebits.nl/fullchain.pem ssl_key = </etc/letsencrypt/live/webmail.feedmebits.nl/privkey.pem
On 03/02/2018 07:51 PM, ɹןʇnqן wrote:
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
On Mar 1, 2018, at 11:01, Maarten mailinglists@feedmebits.nl wrote:
I'm using letsencrypt certificates with roundcube and I'm not having any issues.
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
verify_peer was added in php 5.6.0 so if you are running a lower version that option won't work.
On 03/02/2018 08:28 PM, Maarten wrote:
https://secure.php.net/manual/en/context.ssl.php
On 03/02/2018 08:22 PM, Maarten wrote:
Or you could try setting verify_peer => false
On 03/02/2018 08:20 PM, Maarten wrote:
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.
On 2018-03-02 20:09, Maarten wrote:
ssl_cert = </etc/letsencrypt/live/webmail.feedmebits.nl/fullchain.pem ssl_key = </etc/letsencrypt/live/webmail.feedmebits.nl/privkey.pem
On 03/02/2018 07:51 PM, ɹןʇnqן wrote:
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
On Mar 1, 2018, at 11:01, Maarten mailinglists@feedmebits.nl wrote:
I'm using letsencrypt certificates with roundcube and I'm not having any issues.
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
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.
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.
On 03/03/2018 12:04 AM, LuKreme wrote:
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.
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?
'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.
On Mar 3, 2018, at 05:03, ɹןʇnqן, lbutler+roundcube@covisp.net wrote:
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.
-
"ɹןʇnqן, " -
barul -
LuKreme -
Maarten -
NederHost/Sebastiaan Hoogeveen -
Vincent Van Houtte -
ɹןʇnqן