svarshavchik
commented
6 years ago The only real reason for using separate files is to use different file permissions for the private key file, that's the only secret part, while the certificate itself can be publically readable. Furthermore, private key can be passphrase-protected, but that's a non-starter for daemons that get started at system boot without any interactive environment to protect anyone for the password to decrypt it. There is no real reason to have the the imap, pop3, and the smtp servers publically readable. There's no harm to it but neither there is a reason to have them publicly readable, without divulging the private key.
I am not opposed to having a separate file for the private key, however there needs to be a fallback default, back to a combined file, if the private key file is not specified. Nobody who's already using a combined file setup should have to do anything when updating.
This will also avoid the need to do anything about the mkimapcert, mkesmtpcert, and mkpop3cert helper scripts. They can continue to generate a single file with a self-signed cert.
mumumu
As you know, [imapd|pop3d].pem file includes cert file and private key file.
Yes, this rule is not illegal for TLS protocol, but this is a pitfall, because TLS certificate file and private key is usually separated each other. So, I was at pains to incorporate letsencrypt cert file into courier imapd-ssl.
Based on this problem, I propose the following ideas.
TLS_PRIVATE_KEYFILEsetting and existingTLS_CERTFILEonly includes cert pem file only.TLS_PRIVATE_KEYFILEis not acceptable, we should mention about the troublesome rule inTLS_CERTFILEcomment.How do you think?