OS: Ubuntu 20.04.2 (on mutli-core VM)
Dovecot (Ubuntu default/repo version):? 2.3.7.2 (3c910f64b)
OpenSSL (Ubuntu default/repo version):? 1.1.1f? 31 Mar 2020
Reproducing-
Run:? "openssl s_client -showcerts -connect imap.example.com:993
-servername imap.example.com" (using a diff domain obviously)
Produces error: "Verify return code: 21 (unable to verify the first
certificate)" (Meaning it is missing a CA verify from what I understand?)
The "Verify return code: 21" error ONLY came to my attention after I
had
a customer complain about adding an email account to an Android phone
(using the Google/Gmail default email app). -> "Certificate cannot be
trusted" was shown by app when verifying imap connection. I could force
it to be used, but this still bothered me, obviously. *The same
certificate bundle is also used by smtp/postifx and www/nginx and works
just fine. Also the openssl test shows 'verified' on both*
I am posting to list mainly because on an older version of Dovecot I
have running (default repo version for Ubuntu 18), I do not have this
problem shown during testing with openssl. I did not have to change the
ssl_cert or ssl_ca value in config. It has identical local.conf settings
other than that. Granted it is also an older openssl version, too. So, I
feel this may be a bug with Dovecot (or possibly OpenSSL).
I finally 'fixed' it myself by using the LE 'fullchain.pem'
certificate
as the location for the 'ssl_cert' entry (and chain.pem for the ca
entry). Previously, it was using the normal cert.pem file location. This
is still the way it's setup on the other older machine and still works
fine. Changes-
|ssl_ca = </etc/letsencrypt/live/{CertName}/chain.pem (or
'fullchain.pem' should work) *ssl_cert =
</etc/letsencrypt/live/{CertName}/fullchain.pem* (was 'cert.pem'
previously) ssl_key = </etc/letsencrypt/live/{CertName}/privkey.pem|
You can also view the problem here for more info :
https://superuser.com/a/1640778/47628
Thanks ahead for any insight into this..
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://dovecot.org/pipermail/dovecot/attachments/20210410/edafd8a5/attachment.html>
> On 10/04/2021 19:09 Brady Shea <bshea at sheacomputers.net> wrote: > > > OS: Ubuntu 20.04.2 (on mutli-core VM) > Dovecot (Ubuntu default/repo version): 2.3.7.2 (3c910f64b) > OpenSSL (Ubuntu default/repo version): 1.1.1f 31 Mar 2020 > > Reproducing- > > Run: "openssl s_client -showcerts -connect imap.example.com:993 -servername imap.example.com" (using a diff domain obviously) > > Produces error: "Verify return code: 21 (unable to verify the first certificate)" (Meaning it is missing a CA verify from what I understand?) > > The "Verify return code: 21" error ONLY came to my attention after I had a customer complain about adding an email account to an Android phone (using the Google/Gmail default email app). -> "Certificate cannot be trusted" was shown by app when verifying imap connection. I could force it to be used, but this still bothered me, obviously. *The same certificate bundle is also used by smtp/postifx and www/nginx and works just fine. Also the openssl test shows 'verified' on both* > > I am posting to list mainly because on an older version of Dovecot I have running (default repo version for Ubuntu 18), I do not have this problem shown during testing with openssl. I did not have to change the ssl_cert or ssl_ca value in config. It has identical local.conf settings other than that. Granted it is also an older openssl version, too. So, I feel this may be a bug with Dovecot (or possibly OpenSSL). > > I finally 'fixed' it myself by using the LE 'fullchain.pem' certificate as the location for the 'ssl_cert' entry (and chain.pem for the ca entry). Previously, it was using the normal cert.pem file location. This is still the way it's setup on the other older machine and still works fine. Changes- > > |ssl_ca = </etc/letsencrypt/live/{CertName}/chain.pem (or 'fullchain.pem' should work) *ssl_cert = </etc/letsencrypt/live/{CertName}/fullchain.pem* (was 'cert.pem' previously) ssl_key = </etc/letsencrypt/live/{CertName}/privkey.pem| > > You can also view the problem here for more info : https://superuser.com/a/1640778/47628 > > Thanks ahead for any insight into this.. > > >In 2.2 it was an unfortunate mistake that ssl_ca was concatenated with ssl_cert. In 2.3 this was fixed to work as it should, as in, ssl_ca is used to *verify* incoming connections and ssl_cert needs to contain the full chain certificate. Aki
On 2021-04-10 12:09 p.m., Brady Shea wrote:> > I finally 'fixed' it myself by using the LE 'fullchain.pem' > certificate as the location for the 'ssl_cert' entry (and chain.pem > for the ca entry). Previously, it was using the normal cert.pem file > location. This is still the way it's setup on the other older machine > and still works fine. Changes- > > |ssl_ca = </etc/letsencrypt/live/{CertName}/chain.pem (or > 'fullchain.pem' should work) *ssl_cert = > </etc/letsencrypt/live/{CertName}/fullchain.pem* (was 'cert.pem' > previously) ssl_key = </etc/letsencrypt/live/{CertName}/privkey.pem|/etc/letsencrypt/live/README: `[cert name]/privkey.pem`? : the private key for your certificate. `[cert name]/fullchain.pem`: the certificate file used in most server software. `[cert name]/chain.pem`??? : used for OCSP stapling in Nginx >=1.3.7. `[cert name]/cert.pem`???? : will break many server configurations, and should not be used ???????????????? without reading further documentation