Someone recently upgraded the SSL certificate on one of my servers the other day, and after a few days bounce messages began trickling in:
TLS connect failed: error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3 alert unexpected message; connected to x.x.x.x.
It was an odd error message, and I couldn't find anything related to qmail. The closest result seemed to suggest it might be an issue with the remote MTA, but I checked with a few of the owners of bouncing servers and they hadn't made any changes recently.
Understanding SSL Chaining
At some level (OS or application) there are Trusted Root Certification Authorities (CA's). If you have a SSL certificate signed by a root CA, it's referred to as a single root certificate. If a CA does not own it's own root certificate, or if their root certificate is relatively new (like GoDaddy a few years ago) and not in a high percentage of browsers they must use a Chained Root to guarantee trust. A CA with a Trusted Root Certificate will issue a Chained Certificate that can then be used by the lower CA to issue certificates that will eventually be trusted. You can have up to eight sections (intermediate CAs) in a chained certificate, and they must be in the proper order in the .crt file that will be sent to the browser.
There are allegedly compatibility issues with chained certificates, and vendors of single root certificates love to tout the fact that a single root is a sign of a stability and trust. To a point you get what you pay for, but I've had very few problems with a $30 SSL certificate from GoDaddy which is chained to their own Trusted Root CA. It does allow for some price differentiation, even though the protection your data receives is the same.
Fixing qmail
The problem turned out to be a missing intermediate bundle for a chained certificate from GoDaddy. Without that bundle remote MTAs couldn't verify the identity of my email server, and were failing, albeit somewhat cryptically. I blew away qmail's old certificates (clientcert.pem and servercert.pem) and generated new ones. ssl_cert.key and ssl_cert.crt are the key and certificate used by Apache, and gd_intermediate_bundle.crt is the intermediate bundle from GoDaddy for Apache 1/2.
Install a new qmail SSL Certificate
Once I realized what the problem was, it was time reinstall the SSL certificates.
# cat /path/to/ssl_cert.key /path/to/ssl_cert.crt /path/to/gd_intermediate_bundle.crt > /var/qmail/control/servercert.pem # ln -s /var/qmail/control/servercert.pem /var/qmail/control/clientcert.pem # chown -h qmaild:root /var/qmail/control/clientcert.pem # chmod 400 /var/qmail/control/servercert.pem # qmailctl restart
Create a new file called servercert.pem containing your .key, .crt and chained certificate. Symlink that to clientcert.pem, set permissions, and restart qmail. Notice the -h option passed to chown for clientcert.pem – this is important, it sets the user/group of the symlink, not the target (referent) of the sylink. The files going into servercert.pem will vary depending on your CA.
If you'd like to use the same certificate for Courier-IMAP's imap-ssl and pop3-ssl daemons:
ln -s /var/qmail/control/servercert.pem /usr/lib/courier-imap/share/imapd.pem ln -s /var/qmail/control/servercert.pem /usr/lib/courier-imap/share/pop3d.pem
Then update your imapd-ssl and pop3d-ssl config files and provide the correct value for the TLS_CERTIFICATE parameter. Restart those services, reconfigure your email client, and rejoice as none of your packet-sniffing friends at work will be able to read your scintillating email conversation on dinner plans.



October 20th, 2011 at 2:05 pm
[...] Finally, the RPM update for qmail-toaster overrides your SSL certificates for SMTP. To restore my real certificates, I had to perform the following steps (lifted from coregilmore.com): [...]