> On 10/04/2021 19:09 Brady Shea <[email protected]> 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

Reply via email to