Hi Sam My certificates (fullchain.pem) key format is ECDSA with SHA-384.
Looks like this is an obscure problem with OpenSSL. But I can not switch to GnuTLS right now. Regards. Sam Varshavchik <[email protected]> 於 2026年3月13日週五 下午5:20寫道： > Neko Chang writes: > > > »Hi All > > > > > > Courier-imap using Let's Encrypt certificates work fine with OpenSSL v1.x > > But the problem occurred after upgrade OpenSSL v3.0 in last year. > > This month upgrade OpenSSL v3.5 still. > > The Let's Encrypt certificates work fine with other server like > Postfix, > > Apache and vsftpd in same all condition. > > > > > > After Google. I had been check <URL:https://sourceforge.net/p/courier/ > > mailman/courier-users/thread/CAMO9ifvubdC6uQ60FRdB3a7- > > akyc%2BwDSyEtc02yv7OHpao64_Q%40mail.gmail.com/#msg45940453>Thread: > [courier- > > users] Problems connecting to imap after upgrade of openssl to v3 and > > follows <URL: > https://help.heroku.com/88GYDTB2/how-do-i-configure-openssl-to- > > allow-the-use-of-legacy-cryptographic-algorithms>How do I configure > OpenSSL > > to allow the use of legacy cryptographic algorithms > > Talking about fixed by OpenSSL v3.5 support legacy cryptographic > algorithms > > I'm follows to config openssl.cnf and result as follows > > Both links you cited described the issue as: the certificate is encrypted > by > a legacy algorithm that OpenSSL 3.5 does not support by default. Because > in > this day and age it's considered to be insecure, in some form or fashion. > > If true, then this is going to remain true no matter which application > uses > OpenSSL. Just because Apache or vsftpd loads the same certificate using > OpenSSL doesn't automatically change the certificate, in some mysterious > manner, to be suddenly using a different cipher. As Mr. Spock would say: > "This is not logical". > > I'm only going to guess is that those other applications employ some > obscure > OpenSSL API to automatically enable legacy cipher support in OpenSSL, > when > they initialize the library, even if that's not enabled by the default > configuration. > > That's fine and dandy, I suppose. But what this really does – and > assuming > OpenSSL's description of the issue is taken for granted as correct – then > re-encoding the certificate is the right solution. Automatically enabling > legacy support in OpenSSL, somehow, sweeps this issue under the rug. > People > wouldn't even be aware of it. That's wrong from the security standpoint. > > So, either OpenSSL is blowing smoke up everyone's derrieres, or > reencoding > the certificate, manually, is the right solution. Now, what also might be > happening is that both Apache and vsftp decided that not automatically > breaking existing setups is more important then whatever OpenSSL's beef > is. > It might very well be that OpenSSL's approach is bonkers, and Apache and > vsftpd are just working around the brain damage. That's entirely > possible, > but I haven't seen any argument in favor of this interpretation. > > Perhaps one way to solve this problem is to determine what GnuTLS does, > here. Does GnuTLS also do the same thing: disable these ciphers and force > certs to be reencoded, by default? > > _______________________________________________ > Courier-imap mailing list > [email protected] > Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap > -- Regards, Wei-Jen Chang
_______________________________________________ Courier-imap mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
