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,
I'm not sure to understand what you ask, can you be more precise ? What I can say is that It's a CentOS 7 server, the package ca-certificates has been updated (to eliminate this "DST Root CA X3" expired). The SSL certificate for exim+dovecot+Sogo has been generated with Letsencrypt.
The problem appeared suddenly and exactly on oct-01, when this "DST Root CA X3" expired, and there was no other change on the server at this date : so I have supposed it was related, but I don't know if it's the case, and how to debug that.

[EDIT] If you asked for the Letsencrypt CA certificate generated with the SSL one, here it is :

# openssl x509 -in ssl.letsencrypt.ca -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            91:2b:08:4a:cf:0c:18:a7:53:f6:d6:2e:25:a7:5f:5a
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Internet Security Research Group, CN=ISRG Root X1
        Validity
            Not Before: Sep  4 00:00:00 2020 GMT
            Not After : Sep 15 16:00:00 2025 GMT
        Subject: C=US, O=Let's Encrypt, CN=R3
        Subject Public Key Info:
...

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.
Now please check, if that is actually in ca-certificates directory (it should) and has a hash linking to it.
ls -l /etc/ssl/certs/ISRG_Root_X1.pem
lrwxrwxrwx 1 root root 51 Okt 14 2017 /etc/ssl/certs/ISRG_Root_X1.pem -> /usr/share/ca-certificates/mozilla/ISRG_Root_X1.crt

ls -l /etc/ssl/certs/4042bcee.0
lrwxrwxrwx 1 root root 16 Okt 14 2017 /etc/ssl/certs/4042bcee.0 -> ISRG_Root_X1.pem

Then check, if your imap server is actually using that new let'sencrypt certificate.
If in doubt, reload it.

Well, it's a CentOS system and there is no directories by CA cert, but bundles :
ls -l /etc/ssl/certs/
lrwxrwxrwx 1 root root 49 1 oct. 13:21 ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
lrwxrwxrwx 1 root root 55 1 oct. 13:21 ca-bundle.trust.crt -> /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
-rw------- 1 root root 1501 15 avril 2016 localhost.crt
-rwxr-xr-x 1 root root 610 4 août 2017 make-dummy-cert
-rw-r--r-- 1 root root 2516 4 août 2017 Makefile
-rwxr-xr-x 1 root root 829 4 août 2017 renew-dummy-cert

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.
To be complete, I forced the generation of a new certificate via letsencrypt, then restart dovecot, exim and sogo.
The auxilliary account doesn't show anything as before :(

Is ISRG_Root_X1 in those bundles?

It seems, yes :
grep 'ISRG Root X1' /etc/ssl/certs/ca-bundle.crt says :
ISRG Root X1

but "grep 'DST Root CA X3' /etc/ssl/certs/ca-bundle.crt" shows nothing.

Using trust :
trust list | grep -C3 'ISRG'
pkcs11:id=%79%b4%59%e6%7b%b6%e5%e4%01%73%80%08%88%c8%1a%58%f6%e9%9b%6e;type=cert
type: certificate
label: ISRG Root X1
trust: anchor
category: authority

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.

Capture d’écran_2021-10-07_12-02-23.png (41,241 bytes)   

Capture d’écran_2021-10-07_12-02-23.png (41,241 bytes)   

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

openssl s_client -starttls imap -servername 10.0.0.15 -connect 10.0.0.15:143
 depth=1 C = US, O = Let's Encrypt, CN = R3
 verify error:num=20:unable to get local issuer certificate
 [...]
     Verify return code: 20 (unable to get local issuer certificate)

So I add to its configuration the new ca file generated with the last cert :
ssl_ca = </xxxxxxxxxxxxxx/ssl.letsencrypt.ca

After restart, it was better

openssl s_client -starttls imap -servername 10.0.0.15 -connect 10.0.0.15:143
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = systea.fr
verify return:1
[...]
    Verify return code: 0 (ok)

Now I'm sure that the correct certificate is used and that dovecot returns a correct answer. But sogod continue to cry :

2021-10-08 11:09:30.462 sogod[4469] SSL(cert_verify_callback): Certificate validation failed
2021-10-08 11:09:30.462 sogod[4469] ERROR(-[NGActiveSSLSocket startTLS]): couldn't setup SSL connection on host 10.0.0.15 (error:00000001:lib(0):func(0):reason(1))...
Oct 08 11:09:30 sogod [4469]: <0x0x564d83b9c3f0[NGImap4Client]> Could not start TLS.
Oct 08 11:09:30 sogod [4469]: <0x0x564d83b9c3f0[NGImap4Client]> ERROR(-[NGImap4Client _processUnknownCommandParserException:]): catched non-IMAP4 parsing exception NGSocketShutdownDuringWriteException: the socket was shutdown
Oct 08 11:09:30 sogod [4469]: [ERROR] <0x0x564d833128f0[NGImap4ConnectionManager]> IMAP4 login failed:
  host=10.0.0.15, user=info@example.com, pwd=yes
  url=imaps://info%40example.com@10.0.0.15/?tls=YES&tlsVerifyMode=default
  base=(null)
  base-class=(null))
  = <0x0x564d83b9c3f0[NGImap4Client]: login=info@example.com(pwd) socket=<NGActiveSocket[0x0x564d83b9d260]: mode=rw address=<0x0x564d83b9d2f0[NGInternetSocketAddress]: host=sogo.example.com port=41756>>>
Oct 08 11:09:30 sogod [4469]: <0x564d83b9bca0[SOGoMailAccount]:1> renewing imap4 password
2021-10-08 11:09:30.504 sogod[4469] SSL(cert_verify_callback): Certificate validation failed
2021-10-08 11:09:30.505 sogod[4469] ERROR(-[NGActiveSSLSocket startTLS]): couldn't setup SSL connection on host 10.0.0.15 (error:00000001:lib(0):func(0):reason(1))...
Oct 08 11:09:30 sogod [4469]: <0x0x564d83b8c840[NGImap4Client]> Could not start TLS.
Oct 08 11:09:30 sogod [4469]: <0x0x564d83b8c840[NGImap4Client]> ERROR(-[NGImap4Client _processUnknownCommandParserException:]): catched non-IMAP4 parsing exception NGSocketShutdownDuringWriteException: the socket was shutdown
Oct 08 11:09:30 sogod [4469]: [ERROR] <0x0x564d833128f0[NGImap4ConnectionManager]> IMAP4 login failed:
  host=10.0.0.15, user=info@example.com, pwd=yes
  url=imaps://info%40example.com@10.0.0.15/?tls=YES&tlsVerifyMode=default
  base=(null)
  base-class=(null))
  = <0x0x564d83b8c840[NGImap4Client]: login=info@example.com(pwd) socket=<NGActiveSocket[0x0x564d83b8ce00]: mode=<closed> address=<0x0x564d83b8c5c0[NGInternetSocketAddress]: host=sogo.example.com port=41758>>>
Oct 08 11:09:30 sogod [4469]: [ERROR] <0x564d83b9bca0[SOGoMailAccount]:1> Could not connect IMAP4

And same thing with SSL :

2021-10-08 11:15:58.128 sogod[4464] SSL(cert_verify_callback): Certificate validation failed
2021-10-08 11:15:58.128 sogod[4464] ERROR(-[NGActiveSSLSocket startTLS]): couldn't setup SSL connection on host 10.0.0.15 (error:00000001:lib(0):func(0):reason(1))...
Oct 08 11:15:58 sogod [4464]: [ERROR] <0x0x564d83311b20[NGImap4ConnectionManager]> IMAP4 login failed:
  host=10.0.0.15, user=info@example.com, pwd=yes
  url=imaps://info%40example.com@10.0.0.15/?tls=NO&tlsVerifyMode=default
  base=(null)
  base-class=(null))
  = <0x0x564d836a7910[NGImap4Client]: login=info@sexample.com(pwd) address=<0x0x564d836a81d0[NGInternetSocketAddress]: host=10.0.0.15 port=993>>
Oct 08 11:15:58 sogod [4464]: <0x564d836a71c0[SOGoMailAccount]:1> renewing imap4 password
2021-10-08 11:15:58.159 sogod[4464] SSL(cert_verify_callback): Certificate validation failed
2021-10-08 11:15:58.160 sogod[4464] ERROR(-[NGActiveSSLSocket startTLS]): couldn't setup SSL connection on host 10.0.0.15 (error:00000001:lib(0):func(0):reason(1))...
Oct 08 11:15:58 sogod [4464]: [ERROR] <0x0x564d83311b20[NGImap4ConnectionManager]> IMAP4 login failed:
  host=10.0.0.15, user=info@example.com, pwd=yes
  url=imaps://info%40info@example.com@10.0.0.15/?tls=NO&tlsVerifyMode=default
  base=(null)
  base-class=(null))
  = <0x0x564d836a90f0[NGImap4Client]: login=info@info@example.com(pwd) address=<0x0x564d83761ac0[NGInternetSocketAddress]: host=10.0.0.15 port=993>>
Oct 08 11:15:58 sogod [4464]: [ERROR] <0x564d836a71c0[SOGoMailAccount]:1> Could not connect IMAP4

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.
BUT, this causes trouble to Sogo. So we used 10.0.0.15 as a workaround, and it worked without errors, specially no SSL errors (even if the certificate was generated on the DNS name).
BUT, again, since october 1st, and this root cert DST X3 expired, the SSL connection to the IP stopped working, don't really know why and how.

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.