Fixing the google error for fetchmail on a Synology DS412+

I’m using my DS412 to centrally collect my mail from various mail boxes I have around the world. One of the mail account I have is with Google.

Unfortunately out of the box fetchmail gives all kind of weird SSL errors which prohibit normal use. These problems can be fixed. This blog explains how this can be done.

The problem

When I run fetchmail imap.gmail.com I get the following output:

fetchmail: Server certificate verification error: unable to get local issuer certificate
fetchmail: This means that the root signing certificate (issued for /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA) is not in the trusted CA certificate locations, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of –sslcertpath and –sslcertfile in the manual page.
9429:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:984:
fetchmail: SSL connection failed.
fetchmail: socket error while fetching from xxxxx@gmail.com@imap.gmail.com
fetchmail: Query status=2 (SOCKET)

So lot’s and lots of nasty errors. This error is caused by the fact that one of the certificates that is being used by Google can not be found by the SSL libraries that is used by fetchmail.

The solution is that you import these certificates and configure fetchmail to use the imported certificates.

Importing the certificates

My first hint I got from http://geekmush.wordpress.com/2007/06/29/how-to-make-fetchmail-happy-with-the-servers-ssl-cert/

This site explains that you have to issue the command:

openssl s_client -connect imap.gmail.com:993 -showcerts

After which you can cut and past the certificates into some .pem files. In this case there are 3 certificates and I named the files 1.pem, 2.pem and 3.pem. The actual names are not important. The files should be stored in a directory that contains nothing but these certificates. In my case I used the directory /volume1/homes/certs

The next step is to run the command c_rehash. This is a command that should come from the SSL toolkit but unfortunately this command is not present on a Synology server. Fortunately this can be easily solved using the following command:

for file in *.pem; do ln -s $file `openssl x509 -hash -noout -in $file`.0; done

This will create a number of symlinks that point with some hash towards the certificate file. This is the mechanism used by the SSL to find which certificate file contains which certificate.

Changing the fetchmail configuration

The next step is to change the fetchmail configuration.

poll imap.gmail.com with proto imap port 993
user ‘xxxxx@gmail.com’ there is xxxxx here fetchall ssl
password ‘your_secret_password’
sslcertck
sslcertpath /volume1/homes/cert.

The sslcertck keyword tells fetchmail that the certificates must be checked and they must match. It will stop working if there is no match.

The sslcertpath command specifies in which directory the certificates reside.

And then it didn’t work

Next is to try and to my disappointment it didn’t work.

The error message is identical to the initial error message. Somehow we didn’t get all the certificates. I learned from http://grox.net/sysadm/net/fetchmail.ssl that the trick is to get the certificate from Equifax directly from their servers. The following command does the job:

curl https://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Certificate_Authority.cer > equifax.pem

After that the line that creates the symlinks needs to be run again:

for file in *.pem; do ln -s $file `openssl x509 -hash -noout -in $file`.0; done

And now it works

After this final change the system runs without any warnings.