We run monit on a number of clients' Linux systems to ensure that all their server daemons keep running as necessary. In this post I describe an issue that arises due to conflicting default SSL/TLS protocols in Zarafa and monit, along with a monit configuration change to work around the issue.
The problem
Yesterday one of the servers we maintain started complaining that the Zarafa IMAP/POP3 gateway wasn't working. When I logged into the server, I was puzzled, as the zarafa-gateway daemon was running and responding as normal to my manual tests.
After some poking around, I discovered that monit was failing to connect to the gateway over SSL only. Unencrypted connections were working fine. Further manual testing using openssl revealed that the gateway only responded when using SSLv3. Connections using SSLv2 or TLS consistently failed.
The fix
I couldn't find an option in the Zarafa config to specify the SSL/TLS version to use. However, I discovered that monit allows the version to be specified. I changed the monit config to force it to connect using SSLv3. Lo and behold, the services were then correctly picked up by monit.
Here's a sample monit config snippet, in case it's useful to anyone who runs into the same problem. Note the sslv3 option on the SSL connections. Hopefully one day soon the Zarafa team will add TLS support to their code so this won't be necessary any more!
check process zarafa-gateway with pidfile /var/run/zarafa-gateway.pid group zarafa start program = "/sbin/service zarafa-gateway start" stop program = "/sbin/service zarafa-gateway stop" if failed port 143 protocol imap then restart if failed port 993 type tcpssl sslv3 protocol imap then restart if failed port 995 type tcpssl sslv3 protocol pop then restart if 5 restarts within 5 cycles then timeout