Re: Letsencrypt/OpenSSL test - Verify return code: 21
On 11/04/2021 01:04, @lbutlr wrote: > On 10 Apr 2021, at 12:57, Juri Haberland wrote: >> On 10/04/2021 19:52, @lbutlr wrote: >>> On 10 Apr 2021, at 09:55, B Shea wrote: OpenSSL (Ubuntu default/repo version): 1.1.1f 31 Mar 2020 >>> >>> There have been a few critical patches to open SSL in the last year, >>> including a very important one to 1.1.1k just recently. >>> >>> Not to do with your issue, but I suspect updating both openssl and Dovecot >>> are good first steps. >> >> That is the version as distributed by Ubuntu with security fixes >> backported as usual for most Linux distributions... > > If the date is May 2020, then no, it hasn't. > > As I said, there have been many patches since then, including one very > important one very recently (end of march, beginning of April). > $ lsb_release --description Description:Ubuntu 20.04.2 LTS $ openssl version OpenSSL 1.1.1f 31 Mar 2020 $ dpkg -l | grep openssl ii openssl1.1.1f-1ubuntu2.3 amd64Secure Sockets Layer toolkit - cryptographic utility $ zcat /usr/share/doc/openssl/changelog.Debian.gz | head -n 16 openssl (1.1.1f-1ubuntu2.3) focal-security; urgency=medium * SECURITY UPDATE: NULL pointer deref in signature_algorithms processing - debian/patches/CVE-2021-3449-1.patch: fix NULL pointer dereference in ssl/statem/extensions.c. - debian/patches/CVE-2021-3449-2.patch: teach TLSProxy how to encrypt <= TLSv1.2 ETM records in util/perl/TLSProxy/Message.pm. - debian/patches/CVE-2021-3449-3.patch: add a test to test/recipes/70-test_renegotiation.t. - debian/patches/CVE-2021-3449-4.patch: ensure buffer/length pairs are always in sync in ssl/s3_lib.c, ssl/ssl_lib.c, ssl/statem/extensions.c, ssl/statem/extensions_clnt.c, ssl/statem/statem_clnt.c, ssl/statem/statem_srvr.c. - CVE-2021-3449 -- Marc Deslauriers Mon, 22 Mar 2021 07:37:17 -0400 So yes, it is up-to-date. Cheers, Juri
Re: Letsencrypt/OpenSSL test - Verify return code: 21
On 10 Apr 2021, at 12:57, Juri Haberland wrote: > On 10/04/2021 19:52, @lbutlr wrote: >> On 10 Apr 2021, at 09:55, B Shea wrote: >>> OpenSSL (Ubuntu default/repo version): 1.1.1f 31 Mar 2020 >> >> There have been a few critical patches to open SSL in the last year, >> including a very important one to 1.1.1k just recently. >> >> Not to do with your issue, but I suspect updating both openssl and Dovecot >> are good first steps. > > That is the version as distributed by Ubuntu with security fixes > backported as usual for most Linux distributions... If the date is May 2020, then no, it hasn't. As I said, there have been many patches since then, including one very important one very recently (end of march, beginning of April). -- Greedo didn't shoot first, motherfucker!
Re: Letsencrypt/OpenSSL test - Verify return code: 21
On 10/04/2021 19:52, @lbutlr wrote: > On 10 Apr 2021, at 09:55, B Shea wrote: >> OpenSSL (Ubuntu default/repo version): 1.1.1f 31 Mar 2020 > > There have been a few critical patches to open SSL in the last year, > including a very important one to 1.1.1k just recently. > > Not to do with your issue, but I suspect updating both openssl and Dovecot > are good first steps. That is the version as distributed by Ubuntu with security fixes backported as usual for most Linux distributions... Kind regards, Juri
Re: Letsencrypt/OpenSSL test - Verify return code: 21
On 10 Apr 2021, at 09:55, B Shea wrote: > OpenSSL (Ubuntu default/repo version): 1.1.1f 31 Mar 2020 There have been a few critical patches to open SSL in the last year, including a very important one to 1.1.1k just recently. Not to do with your issue, but I suspect updating both openssl and Dovecot are good first steps. -- what is magic actually for? For fixing things, dummy.
Re: Letsencrypt/OpenSSL test - Verify return code: 21
> On 10/04/2021 19:09 Brady Shea 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 = should work) *ssl_cert = (was 'cert.pem' previously) ssl_key = > > 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
Letsencrypt/OpenSSL test - Verify return code: 21
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 = 'fullchain.pem' should work) *ssl_cert = previously) ssl_key = You can also view the problem here for more info : https://superuser.com/a/1640778/47628 Thanks ahead for any insight into this..
Letsencrypt/OpenSSL test - Verify return code: 21
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 = 'fullchain.pem' should work) *ssl_cert = previously) ssl_key = You can also view the problem here for more info : https://superuser.com/a/1640778/47628 Thanks ahead for any insight into this..
Re: Debug: SSL_get_servername() failed
> On 10/04/2021 01:00 Rowan @ Jetboy wrote: > > > I've setup Postfix to Dovecot LMTP delivery with mandatory TLS. Emails > are being delivered with TLSv1.3 with no errors. However, setting: > > verbose_ssl = yes > > exposes this on each connection: > > lmtp(405619): Debug: SSL_get_servername() failed > > What it this mean, and what should I do about it? It means client did not request any particular servername. That is not an error, it's a debug message. You can try configure postfix to use DNS name instead of IP, but that said, this message is harmless and can be ignored. Aki
