Have you always used an ECDSA certificate? Per searching that error usually relates to a unknown or problem private key. Please do not post the private key here that would require Let's Encrypt to revoke your cert. And, if that same cert and key are working with Apache it must be valid at least to that.
Maybe try reissuing as RSA cert? Use --key-type rsa
Yes, using ECDSA certificate since 2022 (Added line of +key_type = ecdsa).
Based on my (mistake?) impression, courier-imap did not report the problem in 2022?
In my system, all daemon using only one cert and key pair, but only courier-imap got problem...
I will try reissuing as RSA cert use --key-type rsa
Ouch...I'm very sorry, I forgot correct resissue method, please hint me?
Can you explain this more? Has this been working with courier-imap since 2022 and only now started failing?
Are you using a very old version of courier-imap? Because before 2018 it required the private key to be in the same file as the certificate. There was no tls_private_keyfile option back then.
Is modify "renew_before_expiry = 30 days" to 80 days and execute certbot to renew recommended?
courier-imap work well before 2022 or 2023 , and later failing I remember...
No, I follow latest courier-imap with FreeBSD ports always, current version: courier-imap-5.2.11.
I remember your said tls_private_keyfile, because I using courier-imap from 2010
Re-run certbot certificates to verify new Key Type after
Note this is one of the rare times to use --force-renewal. Use it just ONCE. There is no need to manually set/reset the renewal days.
Also, your courier config directory is different than Certbot's. Are you sure the courier files are the same as Certbot's? Could they have become corrupt or damaged in some way?
All fine look like, and restart "courier-imap" daemon to let it use RSA version certificate.
Back to log of 'courier-imap', got same error as follows.
Courier-imap issue look like...
Jul 26 01:08:18 mail imapd-ssl[68235]: ip=[fd00::ffff:a00:3fe], couriertls: /usr/local/etc/courier-imap/certificate/fullchain.pem: error:1E08010C:DECODER routines::unsupported
Sorry you confusing caused.
Because courier-imap runing in jail environment, path of certificate file different than host.
Both synchronize via customization deploy-hook.
Certbot no longer saves the csr file so you can remove that from your post-hook. It was only a temporary file anyway.
As for original error don't have any other guesses.
If you view the certs manually in the courier-imap directory do they look correct? Even use something like diff or cmp to compare them to ensure they copied correctly. Or run md5sum on each and compare hashes
Maybe I do have another guess does that mail program need to be told these are .pem files?
They have openssl V3 per first post. And, have described recompiling Courier IMAP
Do you know of a way to check the version it was compiled with?
Please review the first post and provide more details of the fix you describe. As it is it looks like a quick copy/paste from an AI or web search not directly related to this person's problem.
TLS_CERTFILE and TLS_PRIVATE_KEYFILE require I known currently.
Other relation configure no idea need or not as follows.
TLS_DHCERTFILE
PEM file that stores our Diffie-Hellman cipher pair.
When OpenSSL is compiled to use Diffie-Hellman ciphers instead of RSA you must generate a DH pair that will be used.
In most situations the DH pair is to be treated as confidential, and filename must not be world-readable.
TLS_TRUSTCERTS
Load trusted root certificates from *`pathname`*. *`pathname`* can be a file or a directory.
If a file, the file should contain a list of trusted certificates, in PEM format.
If a directory, the directory should contain the trusted certificates, in PEM format, one per file and hashed using OpenSSL's **c_rehash** script.
`TLS_TRUSTCERTS` is used by SSL/TLS clients (by specifying the `-domain` option) and by SSL/TLS servers (`TLS_VERIFYPEER` is set to `PEER` or `REQUIREPEER`).
does that mail program need to be told these are .pem files?
