Hi all, I've used Dovecot since February 2012, but because I kept reinstalling Linux with every major version, I never had a Dovecot self-signed certificate go bad on me before. Til now. I started using rolling release Void Linux about a year ago, and my Dovecot self-signed certificate just expired. The solution I used is contained in these documents: http://wiki2.dovecot.org/SSL/CertificateCreation http://wiki2.dovecot.org/SSL/CertificateClientImporting file:///etc/ssl/dovecot-openssl.cnf http://www.faqforge.com/linux/renew-the-dovecot-ssl-certificate-on-ubuntu-linux/ I basically moved my old /etc/ssl/certs/dovecot.pem and /etc/ssl/private/dovecot.pem, then edited /etc/ssl/dovecot-openssl.cnf specifically to give myself the common name of 192.168.100.2. I had earlier used my hostname, but that produced a conflict, so I just used the ip address. Then I ran dovecot-mkcert.sh to create the new self-signed cert, and finally, configured Claws-Mail to use /etc/ssl/certs/dovecot.pem as its cert. Obviously, if my Claws-Mail were on a different machine than my Dovecot, I would have had Claws-Mail point to a local copy. Alpine still gives me a bad cert warning, saying I should either fix it or disable checking. I haven't yet found a way to get Alpine to discriminate between a valid self-signed cert and a bad one. Anyway, all's good. SteveT Steve Litt November 2016 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz
On Wed, 23 Nov 2016, Steve Litt wrote:> [snip] > > Alpine still gives me a bad cert warning, saying I should either fix it > or disable checking. I haven't yet found a way to get Alpine to > discriminate between a valid self-signed cert and a bad one. >Like a number of applications, alpine checks the system certificates directory for a file containing the server certificate to be validated that's named according to its x509 hash. If it finds it, it trusts it. I don't know where Linux distros keep their certs, but on FreeBSD it's in /etc/ssl/certs/. If you've no other way to find out, a brute force search of the alpine binary should locate it, e.g.: $ strings $(whence alpine) | grep '^/.*certs$' /etc/ssl/certs You can fetch the certificate from a remote IMAP server and install it in your system certs directory like this: # cd /path/to/certs &&> openssl s_client -connect remote.server:143 -starttls imap -showcerts </dev/null 2>&0 | > H=$(openssl x509 -hash -out imap.pem) && > ln -sf imap.pem ${H}.0# ls -l total 5 lrwxr-xr-x 1 root wheel 11 Nov 23 15:34 3a82ab1a.0 -> imap.pem -rw-r--r-- 1 root wheel 1371 Nov 23 15:34 imap.pem -- Greg Rivers
On Wed, 23 Nov 2016 16:04:22 -0600 (CST) Greg Rivers <gcr+dovecot at tharned.org> wrote:> On Wed, 23 Nov 2016, Steve Litt wrote: > > [snip] > > > > Alpine still gives me a bad cert warning, saying I should either > > fix it or disable checking. I haven't yet found a way to get Alpine > > to discriminate between a valid self-signed cert and a bad one. > > > Like a number of applications, alpine checks the system certificates > directory for a file containing the server certificate to be > validated that's named according to its x509 hash. If it finds it, it > trusts it. > > I don't know where Linux distros keep their certs, but on FreeBSD > it's in /etc/ssl/certs/. If you've no other way to find out, a brute > force search of the alpine binary should locate it, e.g.: > > $ strings $(whence alpine) | grep '^/.*certs$' > /etc/ssl/certsThe directory or the certs isn't the problem. Alpine sees the self-signed cert I just made, but complains because it's self-signed, and gives me the choice between saying "yes" every time, and just not checking for certs at all. SteveT Steve Litt November 2016 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz