I renewed my mail server’s TLS certs the other day and noticed that Alpine had problems verifying my certificate chain. (Yes I still use a text based email).
(Of course after I figured all of this out and changed my Google queries a bit, I found where other people hit the same problem back in 2016 and came to the same conclusion.)
When I ran openssl against my IMAP-SSL server on port 993, the various intermediate certs were okay but I saw this message:
139713136498592:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3636:
Likewise in the courier-imap log I saw this corresponding entry:
imapd-ssl: couriertls: accept: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
Puzzled in that my other Mail clients like on OS X and my iPhone work just fine, and there isn’t a way to twiddle with forcing SSL/TLS protocols that Alpine uses, I started randomly fiddling knobs.
One thing I learned out of all of this that you can actually use curl to speak to an IMAP server. I tried that to see if it gave me any extra insight and it kind of did:
$ curl "imaps://bwann@example.com" curl: (35) SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message.
This lead me to go fiddle with the dhparams.pem file that Courier IMAP depends on. The monthly cron job that runs /usr/lib/courier-imap/sbin/mkdhparams generates Diffie-Helman parameters using a 768-bit key. This seemed sort of puny, so I edited BITS=768 to say BITS=2048, blew away the old dhparams.pem file and generated a new one with 2048 bits.
Now when I run curl without a password, I get an auth failure instead of an SSL error. Ah hah!
$ curl "imaps://bwann@example.com" curl: (67) Authentication failed: 78
Now Alpine works just fine.
