mutt on OpenBSD
This is more of a heads-up as the problem isn't in mutt per se. A while back, mutt stopped working correctly for me on OpenBSD, and of course, I completely failed to take notice at which point and with which release exactly ... What is the problem? When you connect to a server for the first time, mutt prompts to accept the server cert (o)nce or (a)lways, in the latter case, saving it into $certificate_file. If you choose to save the cert, the next time you connect to the server, connection will fail with SSL failed: error:14FFF086:SSL routines:(UNKNOWN)SSL_internal:certificate verify failed The workaround is to accept the certificate (o)nce, for the current session only, every time. I verified this with two different servers and non-overlapping certificate chains. My guess is that the problem is really with libressl and probably started with OpenBSD 7.0 (libressl 3.3.4) or 6.9 (3.3.2). As a test, I installed openssl 1.1.1t from ports and rebuilt the mutt port so that it configures and links against openssl. No more problem. mutt -d 5 wasn't much help in trying to debug this. This is the scenario when the server cert doesn't exist in the certificate file and is added to it [2023-04-25 12:15:23] Looking up disroot.org... [2023-04-25 12:15:23] Connecting to disroot.org... [2023-04-25 12:15:23] ssl_load_certificates: loading trusted certificates [2023-04-25 12:15:23] ssl_socket_open: Error loading trusted certificates [2023-04-25 12:15:23] ssl_verify_callback: checking cert chain entry /CN=disroot.org (preverify: 0 skipmode: 0) [2023-04-25 12:15:23] X509_verify_cert: unable to get local issuer certificate (20) [2023-04-25 12:15:24] Certificate saved [2023-04-25 12:15:25] ssl_cache_trusted_cert: trusted [2023-04-25 12:15:25] ssl interactive_check_cert: done=2 [2023-04-25 12:15:25] TLSv1.3 connection using TLSv1/SSLv3 (TLS_AES_256_GCM_SHA384) [2023-04-25 12:15:26] Connected to disroot.org:993 on fd=4 And this is the scenario where the certificate exists in the file [2023-04-25 12:15:35] Looking up disroot.org... [2023-04-25 12:15:35] Connecting to disroot.org... [2023-04-25 12:15:35] ssl_load_certificates: loading trusted certificates [2023-04-25 12:15:35] SSL failed: error:14FFF086:SSL routines:(UNKNOWN)SSL_internal:certificate verify failed [2023-04-25 12:15:36] Connected to disroot.org:993 on fd=-1 [2023-04-25 12:15:37] mutt_index_menu[831]: Got op 102 [2023-04-25 12:15:37] mutt_buffer_pool_free: 15 of 15 returned to pool It seems libressl has had problems with certificate chains before.
Re: mutt on OpenBSD
On Tue, Apr 25, 2023 at 01:12:18PM +0100, ckeader via Mutt-dev wrote: And this is the scenario where the certificate exists in the file [2023-04-25 12:15:35] Looking up disroot.org... [2023-04-25 12:15:35] Connecting to disroot.org... [2023-04-25 12:15:35] ssl_load_certificates: loading trusted certificates [2023-04-25 12:15:35] SSL failed: error:14FFF086:SSL routines:(UNKNOWN)SSL_internal:certificate verify failed Thank you for the heads-up about the problem. Strange, it is successfully loading the certificates file, but then after calling SSL_connect() it doesn't even get to the point of calling mutt's ssl_verify_callback() function. It just blows up and returns an internal error. [2023-04-25 12:15:36] Connected to disroot.org:993 on fd=-1 [2023-04-25 12:15:37] mutt_index_menu[831]: Got op 102 [2023-04-25 12:15:37] mutt_buffer_pool_free: 15 of 15 returned to pool It seems libressl has had problems with certificate chains before. Just out of curiosity, what happens if you set $ssl_verify_partial_chains? -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: mutt on OpenBSD
On Tue, Apr 25, 2023 at 13:12:18 +0100, ckeader via Mutt-dev wrote: > This is more of a heads-up as the problem isn't in mutt per se. > > A while back, mutt stopped working correctly for me on OpenBSD, and of > course, I completely failed to take notice at which point and with which > release exactly ... > > What is the problem? When you connect to a server for the first time, mutt > prompts to accept the server cert (o)nce or (a)lways, in the latter case, > saving it into $certificate_file. If you choose to save the cert, the next > time you connect to the server, connection will fail with > > SSL failed: error:14FFF086:SSL routines:(UNKNOWN)SSL_internal:certificate > verify failed > > The workaround is to accept the certificate (o)nce, for the current session > only, every time. I verified this with two different servers and > non-overlapping certificate chains. > > My guess is that the problem is really with libressl and probably started > with OpenBSD 7.0 (libressl 3.3.4) or 6.9 (3.3.2). > > As a test, I installed openssl 1.1.1t from ports and rebuilt the mutt port > so that it configures and links against openssl. No more problem. > I recently hit a similar issue on Gentoo when I tried building Mutt using GnuTLS (forgot to note down the versions, but I think it was Mutt 2.2.3 and GnuTLS 3.7.8 according to Portage logs). I backed out when I saw the "accept cert" prompt, though, since I wasn't sure how to proceed, and instead rebuilt it with OpenSSL since it worked before (and continues to do so today). Currently on Mutt 2.2.10. - Oskari signature.asc Description: PGP signature
Re: mutt on OpenBSD
> I recently hit a similar issue on Gentoo when I tried building Mutt > using GnuTLS (forgot to note down the versions, but I think it was Mutt > 2.2.3 and GnuTLS 3.7.8 according to Portage logs). I backed out when I > saw the "accept cert" prompt, though, since I wasn't sure how to > proceed, and instead rebuilt it with OpenSSL since it worked before (and > continues to do so today). > > Currently on Mutt 2.2.10. I saw that ebuild update but haven't updated yet :) In any case, I solved the OpenBSD issue. Problem between keyboard and chair. Setting out to try Kevin's suggestion, I found I had set ssl_usesystemcerts=no. There was a question mark in the comment next to it and I don't remember why I changed away from the default here or what I was checking.
