Error: "The remote certificate is invalid according to validation procedures"

Hi,

First of all thanks a lot for all your work! I really love duplicati and I am using it since some time already.

But since a few weeks I get this error “The remote certificate is invalid according to validation procedures” (german: “Das Remotezertifikat ist laut Validierungsverfahren ungültig”) and I don’t know where it comes from.

My setup: I have duplicati running on Windows 8 / 10 and the backup storage is an HDD connected to my fritz.box. The file transfer happens via FTP. When I created my backup configuration I also checked the option “accept-any-ssl-certificate” but appearently this does not work anymore?
So I tried to import the certificate of my fritz.box on my windows machine, but this also did not help.

Has anything changed 3-4 weeks ago in this regard? And how do I configure my certificate stuff properly?

Thanks in advance!

Thanks for the kind words!

The error message is not from Duplicati itself, it is either from the .Net framework or from Windows.

There have been no changes in Duplicati. Do you happen to have a certificate from either Symantec or StartCom ? Those have recently been marked as “untrusted” by Google and others, so maybe Windows is now blacklisting them?

The --accept-any-ssl-certificate option should work, but maybe the blocking happens before the certificate is passed to Duplicati.

Well, I have some certificates from both of them as “Intermediate Certification Authorities” (“Zwischenzertifizierungsstellen”) and one from StartCom as “Trusted Root Certificate Authorities” (“Vertrauenswürdige Stammzertifizierungsstellen”), but I have no idea when they would be used in my context.

The log output is:

System.Security.Authentication.AuthenticationException: Das Remotezertifikat ist laut Validierungsverfahren ungültig.
bei Duplicati.Library.Main.BackendManager.List()
bei Duplicati.Library.Main.Operation.FilelistProcessor.RemoteListAnalysis(BackendManager backend, Options options, LocalDatabase database, IBackendWriter log, String protectedfile)
bei Duplicati.Library.Main.Operation.FilelistProcessor.VerifyRemoteList(BackendManager backend, Options options, LocalDatabase database, IBackendWriter log, String protectedfile)
bei Duplicati.Library.Main.Operation.BackupHandler.PreBackupVerify(BackendManager backend, String protectedfile)
bei Duplicati.Library.Main.Operation.BackupHandler.Run(String[] sources, IFilter filter)
bei Duplicati.Library.Main.Controller.<>c__DisplayClass16_0.b__0(BackupResults result)
bei Duplicati.Library.Main.Controller.RunAction[T](T result, String[]& paths, IFilter& filter, Action`1 method)
bei Duplicati.Library.Main.Controller.Backup(String[] inputsources, IFilter filter)
bei Duplicati.Server.Runner.Run(IRunnerData data, Boolean fromQueue)

Does this help you?

If the destination certificate is not from StartCom or Symantec, then there should be no issues.

The stack trace reveals that the error does happen during the call to the server, so it is certainly the server certificate that is being rejected for some reason.

If you can get the certificate by some means, that can maybe reveal what the problem is. There is an online tool for this, but I am not sure it works for FTP:

https://www.ssllabs.com/ssltest/

If you can run something on a Linux box, then you can try this SSL tool:

https://testssl.sh/

The storage is not reachable from the public internet, so I guess that the ssltest site does not work for me.
Because of that I just dropped the “Use SSL” flag and it works fine. I would like to have used a secure connection even it is only in my private network, but I am missing the knowledge to fix this problem. Most important part is that the backup works :slight_smile:

Thanks!

If just found the bug that disables this flag periodically:

I have the same issue - when can this be fixed?

What version of Duplicati are you seeing this issue in?

Can you confirm whether or not this has been fixed in any of the Canary releases?

Yes, it is fixed in the latest canary (2.0.2.8):

Is the canary release channel suitable for daily use?

No!

All commits are subjected to testing with continous integration, so you have some confidence that it will not corrupt your backups, but there may be things that are not working (VSS snapshots, UI bugs, etc).

If you use the canary channel, be sure to test that it works as expected.

Is “testing with continuous integration” a link? This is the 2nd set of text I’ve seen recently that looks like it should be a link (blue and “hand” hover) but doesn’t do anything when clicked.

Yes, It seems that the https:// part is missing from the url, which is why it does not work when clicked. Maybe it is a copy-paste error on my end.

I originally posted on github (FTPS certificate is not accepted after some time · Issue #2645 · duplicati/duplicati · GitHub) but this forum is probably the correct place.

I’m new to Duplicati and coming from Crashplan.
I have followed the workaround by masgo but I continue to receive “The remote certificate is invalid according to the validation procedure.” error. I have checked the certificates fingerprint (SHA-1) after importing by going to certmgr.msc > Trusted Root Certificate Authorities > Certificates, then viewing the certificate there. I validated the SHA-1 displayed when connecting to the TLS FTP site in Filezilla. I imported it as both a machine and user certificate.

Any ideas what I’m doing differently than masgo? Other things to try?

@kenkendk When will the fix make it to the Beta channel appropriate for daily use? (Thank you for your development on this platform - it’s very feature-rich.)

EDIT: My issue was because of the certificate domain mismatch. It generated the same Duplicati error but importing didn’t address that. I had to generate a new key that matched the domain name I’m using in duplicati. .e.g. openssl req -x509 -sha256 -nodes -days 7120 -newkey rsa:2048 -keyout ftp.key -out ftp.crt
And be sure to enter the FQDN of your FTP URL at the “Common Name” prompt.

Good question. I have just released a new experimental, which I expect we can bump to a new beta if there are no bad errors found.

1 Like