TLS: SSL_read() failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca: SSL alert number 48

Here's a fun error message that we're getting on our mail server at the office:

Aug 15 10:52:26 fvs-pri dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=172.30.0.221, lip=172.30.0.1, TLS: SSL_read() failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca: SSL alert number 48, session=

The odd thing is that using public SSL testing tools (such as the one at DigiCert) do not indicate any problems with the mail server's SSL configuration. And this only seems to affect some clients, and is possibly only acting up with Dovecot. So my guess is that Apache/OpenSSL is configured correctly, but Dovecot is not.

The key to figuring this out is the "openssl s_client" command:

openssl s_client -connect mail.example.com:143 -starttls imap

This showed us that the openssl library was having problems validating the server's certificate, because the intermediate certificates were not also stored in the certificate file that gets sent to the client. The solution is to adjust the file pointed to by Dovecot's "ssl_cert" argument and add your certificate vendor's intermediate certificates to the end of the file.

The order of the certificates inside that file matters. Your server certificate needs to be first, then list the rest of the certificates in order as you move up the certificate chain to the root CA.

Dovecot fails to compile against PostgreSQL 9.2

If you are trying to compile dovecot against PostgreSQL, then you are probably running configure with the "--with-pgsql" option.  Except that if you installed PostgreSQL via the PGDG repository on Centos 6, you are probably stuck with the following error:

checking for shadow.h... yes
checking for pam_start in -lpam... no
checking for auth_userokay... no
checking for pg_config... NO
checking for PQconnectdb in -lpq... no
configure: error: Can't build with PostgreSQL support: libpq not found

The root cause is that pg_config is not in the PATH statement.  So you should add "/usr/pgsql-9.2/bin" to your PATH statement before calling ./configure.  If you are not sure where pg_config is located, try "find / -name pg_config".

#!/bin/bash
PATH=/usr/pgsql-9.2/bin:$PATH
export PATH
./configure \
        --with-pgsql

Once you do the above, the dovecot 2.2 configure script will run to completion.

Dovecot - Upgrading Notes

At the office, we're using a virtual Dovecot server where each person's mail folders are owned by an unique user in the Linux account system.

Dovecot: Virtual Users - covers the basics

Dovecot: UserIds - explains why we use different UIDs for different accounts

Dovecot: LDA - explains how to setup the "deliver" executable to deal with multiple user IDs.

Multiple UIDs

If you're using more than one UID for users, you're going to have problems running deliver. Most MTAs won't let you run deliver as root, so for now you'll need to make it setuid root. However it's insecure to make deliver setuid-root, especially if you have untrusted users in your system. You should take extra steps to make sure that untrusted users can't run it and potentially gain root privileges. You can do this by placing deliver into a directory where only your MTA has execution access.

All of which means that whenever we update Dovecot with "yum update", we need to make sure that we fix up the Dovecot "deliver" executable file (which uses setuid) to also match.

So let's figure out which "deliver" we need to fix up each time:

# find / -name deliver
/usr/local/libexec/dovecot/lda/deliver
/usr/libexec/dovecot/deliver

Alternately, look at Postfix's master.cf file:

# grep "deliver" /etc/postfix/master.cf
# grep "deliver" /etc/postfix/master.cf
# Many of the following services use the Postfix pipe(8) delivery
# The Cyrus deliver program has changed incompatibly, multiple times.
flags=R user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -m ${extension} ${user}
user=cyrus argv=/usr/lib/cyrus-imapd/deliver -e -r ${sender} -m ${extension} ${user}
# Other external delivery methods.
flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/lda/deliver -f ${sender} -d ${recipient}
# flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d ${recipient}

The key line in that jumble being:

flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/lda/deliver -f ${sender} -d ${recipient}

If we take a look at the file size, ownership, attributes and security settings (for SELinux):

# cd /usr/libexec/dovecot/
# ls -la deliver
-rwxr-xr-x 1 root root 802824 Jul 24 06:32 deliver
# ls -lZ deliver
-rwxr-xr-x root root system_u:object_r:dovecot_deliver_exec_t deliver

# cd /usr/local/libexec/dovecot/
# ls -la
total 24
drwx------ 2 vmail vmail 4096 Jun 16 23:00 lda
# ls -lZ
drwx------ vmail vmail system_u:object_r:bin_t lda

# cd /usr/local/libexec/dovecot/lda/
# ls -la deliver
-rwsr-xr-x 1 root root 802824 Aug 12 18:12 deliver
# ls -lZ deliver
-rwsr-xr-x root root system_u:object_r:dovecot_deliver_exec_t deliver

What we see here is a couple of things regarding how the Dovecot LDA is setup.

1. The Postfix master.cf file controls which "deliver" gets used for local delivery of e-mail. (The "deliver" executable is part of Dovecot, so we're using Dovecot for local delivery.)


2. /usr/local/libexec/dovecot//lda/deliver - this is where our "setuid" version of the "deliver" executable is located


3. The "lda" folder is owned by vmail:vmail (limited access) and only the vmail user can access the contents of the folder. Postfix knows to use the vmail user because that's what we told it to do in the master.cf file.


4. Both the official "deliver" executable (in the /usr/libexec/dovecot/ directory) and our "setuid" copy have the same byte size, date/time, and are both labled as "system_u:object_r:dovecot_deliver_exec_t" for SELinux.

The steps that we take when we update Dovecot are then:

1. yum update dovecot - updates the Dovecot executables to the latest version over at the atrpms repository


2. cp --no-preserve=all /usr/libexec/dovecot/deliver /usr/local/libexec/dovecot/lda/deliver - copies the new deliver executable over to the lda folder where we will setuid on it


3. chmod u+s is what we use to set the setuid bit on the copy in the lda folder, but we shouldn't need to do that once we set things up initially


4. service dovecot restart - restarts the Dovecot service using the new executables


5. grep "AVC" /var/log/audit/audit.log | tail -n 50 - look for any errors relating to Dovecot

Dovecot - CMUSieve Errors

After upgrading our CentOS 5 box to the latest revisions this week (including Dovecot 1.1), we're seeing the following error message in the log files. Sieve was working fine with Dovecot 1.0.

# cat /var/vmail/dovecot-deliver.log

deliver(ruth@example.com): Jul 28 11:11:44 Error: dlopen(/usr/lib64/dovecot/lda/lib90_cmusieve_plugin.so) failed: /usr/lib64/dovecot/lda/lib90_cmusieve_plugin.so: undefined symbol: message_decoder_init
deliver(ruth@example.com): Jul 28 11:11:44 Fatal: Couldn't load required plugins

# ls -l /usr/libexec/dovecot/sievec
-rwxr-xr-x 1 root root 165152 Jun 11 03:21 /usr/libexec/dovecot/sievec

# yum list | grep "dovecot"
dovecot.x86_64 1:1.1.1-2_76.el5 installed
dovecot-sieve.x86_64 1.1.5-8.el5 installed
dovecot.x86_64 1:1.1.2-2_77.el5 atrpms
dovecot-devel.x86_64 1:1.1.2-2_77.el5 atrpms

Not sure yet what went wrong during the upgrade.

...

Update: The problem was that we had made a copy of Dovecot's "deliver" executable to make it setuid to work with virtual user local delivery. After the update, we forgot to update this copy of the exectuable.

Once we updated the setuid copy of "deliver", things worked fine.