View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0005397 | SOGo | Web Mail | public | 2021-10-01 14:16 | 2022-01-19 16:35 |
Reporter | fsoyer | Assigned To | |||
Priority | high | Severity | major | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Platform | [Server] Linux | OS | RHEL/CentOS | OS Version | 7 |
Product Version | 5.0.1 | ||||
Summary | 0005397: SSL error for auxiliary accounts pointing to Sogo servers (local or remote) | ||||
Description | Since today, all auxiliary accounts pointing to imap accounts on Sogo servers do not display anything. For exemple :
I test it with an auxiliary account on local server, same domain, and on another auxiliary account on a remote (sogo) server : same thing. I tried to add :
This url should have change with SOGoIMAPServer, isn't it ? Questions : Is this possible that this can be related to the "DST Root CA X3" bug ? The certificate for Exim and Dovecot is a Lestencrypt one. Sogo is installed on CentOS 7, openssl 1.0.2k. Why the url do not change when changing SOGoIMAPServer ? Please help ? | ||||
Steps To Reproduce | No steps, error comes since this morning without changes. | ||||
Tags | No tags attached. | ||||
Note : this IMAP error does not affect, for example, an Andriod device, or a Thunderbird, connected with IMAP on the account. It seems to affect only the webmail, on auxiliary accounts. |
|
Do you have the corresponding CA certificate on your server? |
|
Hi Christian, |
|
[EDIT] If you asked for the Letsencrypt CA certificate generated with the SSL one, here it is :
Where we can see that it is actually valid, and that the related root cert has been redirected to the valid "ISRG Root X1" instead of the old "DST X3" |
|
Partly the information I wanted :-) Your let'sencrypt certificate already has the "ISRG Root X1" as CA. ls -l /etc/ssl/certs/4042bcee.0 Then check, if your imap server is actually using that new let'sencrypt certificate. |
|
Well, it's a CentOS system and there is no directories by CA cert, but bundles : ca-bundle.trust.crt contains the DST X3 cert, but not tls-ca-bundle.pem. I tried to change "ssl_ca" in dovecot.conf to point to this, then restart : same error. |
|
Is ISRG_Root_X1 in those bundles? |
|
It seems, yes : but "grep 'DST Root CA X3' /etc/ssl/certs/ca-bundle.crt" shows nothing. Using trust : and "trust list | grep -C3 'DST Root CA X3'" shows nothing. |
|
Searching for workarounds (on openssl, or Letsencrypt directly, not only on Sogo or dovecot), I found that on CentOS 7 particularly, updating the CA certs (wich removes the DST X3 from certs) seems to be enough. One example among others : https://forum.virtualmin.com/t/let-s-encrypt-dst-root-ca-x3-centos-7-and-virtualmin/112339. The certificates are up to date on this server (as shown above), I have no other problem (on mu Android connected via imap on it, for example), so I can't figure out why sogo get problems when connecting to imap. Finding a way to debug that would be awesome... |
|
Do you have that now invalid "DST Root CA X3" certificate attached to your let'sencrypt server certificate? |
|
Not sure how to see that on command line, but the cert used in dovecot is the same as this used with the webmail. So I join a screenshot from a browser. No reference to DST X3. |
|
Well, I continue my way :) I found that if the cert was OK, dovecot worked for devices like Android, but did not totally answer correctly
So I add to its configuration the new ca file generated with the last cert : After restart, it was better
Now I'm sure that the correct certificate is used and that dovecot returns a correct answer. But sogod continue to cry :
And same thing with SSL : |
|
Well guys, finally I think I've found the problem. Some explanations for those having a similar problem. As you can see in the traces, the secondary account was declared on '10.0.0.15' which is the internal IP of the server. Why ? Because when we tried to put its DNS public name, Sogo said "not on localhost" because this DNS name was added in the hosts file, pointing to 127.0.0.1. All our servers are configured as this to avoid going out to internet when a call to themself is made. The solution was to remove the DNS public name from /etc/hosts, and declare the secondary account on the public name. Now (and with the certificate regenerated with the new root ISRG Root X1 issuer) it works. So, thank you @Christian Mack to take some time on this (not really explicable) problem. |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2021-10-01 14:16 | fsoyer | New Issue | |
2021-10-01 14:29 | fsoyer | Note Added: 0015506 | |
2021-10-05 10:44 | Christian Mack | Note Added: 0015511 | |
2021-10-05 11:19 | fsoyer | Note Added: 0015513 | |
2021-10-05 11:41 | fsoyer | Note Added: 0015514 | |
2021-10-05 13:01 | Christian Mack | Note Added: 0015515 | |
2021-10-05 13:30 | fsoyer | Note Added: 0015516 | |
2021-10-05 13:35 | Christian Mack | Note Added: 0015517 | |
2021-10-05 13:44 | fsoyer | Note Added: 0015518 | |
2021-10-06 11:15 | fsoyer | Note Added: 0015519 | |
2021-10-07 06:56 | Christian Mack | Note Added: 0015528 | |
2021-10-07 06:57 | Christian Mack | Note Edited: 0015528 | |
2021-10-07 10:07 | fsoyer | Note Added: 0015529 | |
2021-10-07 10:07 | fsoyer | File Added: Capture d’écran_2021-10-07_12-02-23.png | |
2021-10-08 09:26 | fsoyer | Note Added: 0015539 | |
2021-10-13 17:10 | fsoyer | Note Added: 0015547 | |
2022-01-19 16:32 | francis | Description Updated | |
2022-01-19 16:32 | francis | Note Edited: 0015514 | |
2022-01-19 16:34 | francis | Note Edited: 0015539 | |
2022-01-19 16:34 | francis | Note Edited: 0015547 | |
2022-01-19 16:35 | francis | Status | new => closed |
2022-01-19 16:35 | francis | Resolution | open => no change required |