Hi all
After switching from hmail server as backend to postfix/dovecot, roundube isn't able to establish connections to the mail backend anymore. The only difference on the mail backend is, the new mail server required TLSv1.2 or higher and refuces anything else.
From the dovecot debug logs I can see that there is a protocol mismatch while trying to establish a session. It seems roundcube isn't using or offering TLSv1.2 or higher. Interestingly, when running
# openssl s_client -connect imap.server.com:993
even without specifying the protocol/version, a TLSv1.3 connection successfully gets established.
This lets me conclude roundcube could be setting which SSL/TLS version to use. So I'd like to ask, if that's true and if so, if i can configure the versions it should use to avoid protocol mismatch?
Roundcube Webmail
## Release 1.6.1
(yes, i will update, but i first want to get it running again - never change two things at the same time).
Thanks a lot for your help!
Hmmm... maybe the error logs are misleading.
Tcpdumping i found an "Alert (Level: Fatal, Description: Unknown CA)" sent from the client host, terminating the connection. Which I can't explain as it's a letsentcrypt cert on the server host. Now letsencrypt is using an trusted CA which is contained in the client's trust store. So....
If that's correct, the question would rather be "is there a way to force roundcube to not lookup CAs"? Just to test if it's running then.
You can set the certificate validation in the Roundcube config:
// IMAP socket context options
// See https://php.net/manual/en/context.ssl.php
// The example below enables server certificate validation
//$config['imap_conn_options'] = [
// 'ssl' => [
// 'verify_peer' => true,
// 'verify_depth' => 3,
// 'cafile' => '/etc/openssl/certs/ca.crt',
// ],
// ];
// Note: These can be also specified as an array of options indexed by hostname
$config['imap_conn_options'] = null;
If you set verify_peer to false it will not try to verify the certificate at all.
Thanks SKaero.
Setting
'verify_peer' => false
and en suite also setting
$config['imap_auth_type'] = 'PLAIN';
worked.
Still, it would be nice to get CA validation running correctly.
Roundcube is running on Ubuntu Host A, dovecot/postfix on Ubuntu Host B. I'm using letsencrypt certs on dovecot/postfix. Clients on Android or Windows are connecting without issues, not complainig about not being able to validate the CA.
If i correctly understand, CA certs are stored in the hosts certstore. And roundcube is using PHP is using openssl is looking up the certstore for a matching CA cert. Is this correct? So I would have to make sure the related CA cert is in Host B's cert store.
Reading https://letsencrypt.org/certificates/, letsencrypt is using:
ISRG Root X1
ISRG Root X2
With these chain of trust:
RSA Subcriber Cert ← RSA Intermediate (R10 or R11) ← ISRG Root X1
ECDSA Subcriber Cert ← ECDSA Intermediate (E5 or E6) ← ISRG Root X1
ECDSA Subcriber Cert ← ECDSA Intermediate (E5 or E6) ← ISRG Root X2
So i would have to check and make sure, these certs are in th certstore and then it would be expeceted Roundcube is able to validate the CA?
With
awk -v cmd='openssl x509 -noout -subject' '
/BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt
I'm listing all CAs in the certstore and I get hits for
subject=C = US, O = Internet Security Research Group, CN = ISRG Root X1
subject=C = US, O = Internet Security Research Group, CN = ISRG Root X2
The Intermediate Certs i can't find in the trust store, assuming, that's expected.
So it would be up to me to provide Roundcube with the intermediate or fullchain cert?
I tried so using:
'ssl_cert' => '/etc/apache2/ssl/fullchain.pem' (readable for www-data)
which does seem to work.
Am I on the wrong way? Did i miss or missunderstand something?
--
Trying to verify the cert on the console with
openssl verify /etc/apache2/ssl/cert.pem
also fails. That's consistent with roundcube not being able to validate. I will try to find out if i can get the validation working on the console.
Looks correct to me, setting the ssl_cert in the config is a valid way of handling it.
Thanks a lot SKaero.
I was able to solve the problem in the meantime. It turned out, i was not using fullchain.pem on dovecot. Changing this solved the issue, now CA verification works on the clients.
I obv. didn't correctly understand how CA verification works. I had the impression, it should be sufficient for the server to present its cert.pem, since it contains information about the issuing CA, so the client should be able to extract this information and perform a lookup against its CA trust store. However, it seems this is not how it is working. At least not with openssl.
Interestingly I had no issues with this on Android and Windows. I will have to check why this is.