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 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
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

This site explains that you have to issue the command:

openssl s_client -connect -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 with proto imap port 993
user ‘’ there is xxxxx here fetchall ssl
password ‘your_secret_password’
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 that the trick is to get the certificate from Equifax directly from their servers. The following command does the job:

curl > 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.

Comments 2

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.