Insecure POP3: "Server certificate verification error" logs

[Basalt]

Sorry for English language, but I'm pretty sure it is better readable than when I would try German
Feel free to respond in German, I can read it.
One week ago I reported this issue at Synology, but only after 5 days they reacted with some further basic questions. That way, it will take ages :-(
I tried both Dutch and US forums, but no-one responded. Maybe you guys can help me?

I use my Syno to fetch POP3 mails from Hotmail using SSL (-> secure).
Until recently this went fine, but since 2 weeks or so, I get every 5 minutes a few warnings in /var/log/messages, see below.

Oct 12 19:49:03 fetchmail[19899]: [username]Server certificate verification error: unable to get local issuer certificate
Oct 12 19:49:03 fetchmail[19899]: [username]This means that the root signing certificate (issued for /CN=Microsoft Internet Authority) is not in the trusted CA certificate locations, or that c_rehash needs to be run on the certificate directory. For de
Oct 12 19:49:03 fetchmail[19899]: [username]Server certificate verification error: certificate not trusted
Oct 12 19:49:03 fetchmail[19899]: [username]Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!)
Oct 12 19:54:05 fetchmail[19899]: [username]Server certificate verification error: unable to get local issuer certificate
Oct 12 19:54:05 fetchmail[19899]: [username]This means that the root signing certificate (issued for /CN=Microsoft Internet Authority) is not in the trusted CA certificate locations, or that c_rehash needs to be run on the certificate directory. For de
Oct 12 19:54:05 fetchmail[19899]: [username]Server certificate verification error: certificate not trusted
Oct 12 19:54:05 fetchmail[19899]: [username]Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!)
Oct 12 19:59:07 fetchmail[19899]: [username]Server certificate verification error: unable to get local issuer certificate
Oct 12 19:59:07 fetchmail[19899]: [username]This means that the root signing certificate (issued for /CN=Microsoft Internet Authority) is not in the trusted CA certificate locations, or that c_rehash needs to be run on the certificate directory. For de
Oct 12 19:59:07 fetchmail[19899]: [username]Server certificate verification error: certificate not trusted
Oct 12 19:59:07 fetchmail[19899]: [username]Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!)

My "messages" files get fully spammed with this.
As backup, an insecure connection is used, so my password is sent in clear text.
But I still do receive my e-mail though.

Until now, I never did anything with certificates, so installing them manually or running c_rehash (as suggested in the log file) does not seem logical.

Does anyone know about this problem?
Any suggestions?


Please your support.

Best regards,

 

[Cavekeeper]

I can confirm the same issue to my DS.
I noticed also these error logs even if I am using the SSL connection.
These problem occurs since the last DSM or Mail package update.
I will also try to report this issue to the Synology support.

 

[Basalt]

Yes, please report to Synology as well, maybe that will speed up things a little.
Synology website -> Hilfe & Support -> Support-Kontaktformular

Best regards,
Erik.

 

[Cavekeeper]

I´ve got following feedback:

"The developer confirm the log should be harmless, and we will remove it in the future release."

Ok, for my opinion it´s no problem. In case that the POP3 selection works without any problems I will ignore the error logs.
Synology development knows about this issue.

 

[Basalt]

Today I received a similar reply:

Hi,
We have obtain feedback from developer.

Currently it is by design and mail station will leave these warning messages log.
However messages will not cause problem and is not an issue, just an log. We had been recorded the behavior for future improvement, while you should able to use the mail station as normal and should work without problem.

Thank you.

"By design" they changed it in the last version
"However messages will not cause problem" ...apart from spamming the important system log file
"Thank you." ...for nothing

I will try to implement a manual fix myself, will let you know if I succeed.

Best regards,
Erik.

 

[Basalt]

Ok, I have a manual fix this.
Downside is that the fix is gone after you use Roundcube to save POP3 settings (changed or not).
Then you have to re-apply the change.

How to apply the change:
1) Start SSH (e.g. using PuTTY), login as root
2)

cd /volume1/@appstore/MailStation/roundcubemail/ext
ll *fetch

3) Now you should see a file like <username>_fetch, where <username> is the user you configured to fetch e-mails.
4) Edit this file with vi, add "sslcertpath ./.cert" to all instances e-mail accounts with "options ssl".
See basic idea below (addd the red text):

#### "<name@domain.tld>"
poll "pop3.live.com" with protocol POP3 and port 995:
        user "<name@domain.tld>" pass "<password>" is "<localusername>" here
        options ssl [COLOR="#FF0000"]sslcertpath ./.cert[/COLOR]
        no keep
mda "/var/packages/MailStation/target/bin/procmail -m \'/var/packages/MailStation/target/roundcubemail/ext/<localusername>.proc.<name>.<domain>.<tld>\'"
#### "<name@domain.tld>"

5) Save the file, be happy

Best regards,
Erik

 

[identt]

I have the same problem. Meanwhile I had a 1.6GB (!) big fetchmail logFile (var/log/fetchmail) which blocks the Logon of the Webaccess. After I delete it, the webaccess works fine again but this is not the solution.
The file is after short period of time again on 25MB. How can I import the SSL certificates or set down the log level if the warnings are not important?
Unfortunately the solution above doesn't work for me because I don't have the roundcube directory. In the appstore folder I only had the folders "CloudStation" and "Z-Push"

 

[jahlives]

new firmwares have logrotate on board. With that you can easy rotate such big logfiles and compress them

 

[identt]

My version is 4.3-3810 Update 3 on a 1812+, but this is not the solution for the problem which causes the log entries looks like this:

fetchmail: Server certificate verification error: certificate not trusted
fetchmail: Server certificate verification error: unable to verify the first certificate
fetchmail: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!)
fetchmail: Server certificate verification error: unable to get local issuer certificate
fetchmail: This means that the root signing certificate (issued for /C=DE/ST=Niedersachsen/L=Bad Gandersheim/O=Secure-Netz/CN=d65.x-mailer.de/emailAddress=ca@secure-netz.de) 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.

Or am I forced to wait for an update from Synology?