Chained SSL certificates (and qmail error 140943F2)

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.

 

One Response to “Chained SSL certificates (and qmail error 140943F2)”

  1. October Qmail Follow-up » ghidinelli.com Says:

    [...] 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): [...]

Leave a Reply


© 2007-2012, Corey Gilmore | Posts RSS Feed | Comments RSS Feed | Contact

 

The views expressed on these pages are mine alone and not those of any past or present employer. All information presented on this site was obtained lawfully and not through disclosure under the terms of an NDA.