SSL errors with WebDAV target even with accept all cert option

Support
1

I am attempting to back up two Windows 10 computers to a Synology NAS via WebDAV.
I have enabled the “accept all certificates” option to see if it would help, but it hasn’t solved the problem.

It works maybe 10% of the time, but most of the time it fails with something like:

Failed: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
Details: System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
   at System.Net.TlsStream.EndWrite(IAsyncResult asyncResult)
   at System.Net.ConnectStream.WriteHeadersCallback(IAsyncResult ar)
   --- End of inner exception stack trace ---
   at Duplicati.Library.Main.BackendManager.List()
   at Duplicati.Library.Main.Operation.FilelistProcessor.RemoteListAnalysis(BackendManager backend, Options options, LocalDatabase database, IBackendWriter log, String protectedfile)
   at Duplicati.Library.Main.Operation.FilelistProcessor.VerifyRemoteList(BackendManager backend, Options options, LocalDatabase database, IBackendWriter log, String protectedfile)
   at Duplicati.Library.Main.Operation.BackupHandler.PostBackupVerification()
   at Duplicati.Library.Main.Operation.BackupHandler.Run(String[] sources, IFilter filter)
   at Duplicati.Library.Main.Controller.<>c__DisplayClass16_0.<Backup>b__0(BackupResults result)
   at Duplicati.Library.Main.Controller.RunAction[T](T result, String[]& paths, IFilter& filter, Action`1 method)

Any suggestions?

2

There is a problem with the --accept-all-ssl-certificates option in some of the recent canary versions (not the latest and not the beta).

What version are you using?

There is a similar one here, for HiDrive:

3

Welcome to the forum! I edited your post to improve the formating. (Just added ~~~ before and after the output you pasted, please see here for details).

1 Like
4

I’m running 2.0.2.1_beta_2017-08-01. So I technically shouldn’t have this problem as long as I use accept-all-ssl-certificates?

(Ultimately i don’t want to use this option and will either use the specific hash match or get a fully trusted cert, but I’m just trying to get it properly working first.)

Thank you

5

Just too confirm you’re having the same issue mentioned earlier, are you also seeing the “underlying connection was closed” error?

6

Yep, with SSL enabled I get the underlying connection closed and other error messages most of the time. Occasionally it works, which to me is strange. SSL is currently disabled and it works 100% of the time.

7

D’Oh! Sorry, I missed the first post where you flat out showed the error. (Stupid phone interface…)

8

@drwtsn32, did you generate the certificate? If so what method?

Have you tried directly trusting the certificate using the hash?

9

I’m using the default cert on my Synology NAS. It is basically a self-signed cert.

When I first tried setting this up, I trusted only its hash. I had the problem so I changed it to accept all certs to see if it would help.

I could try generating my own cert and trying again with just the hash, if you think it might make a difference. I typically use openssl to generate… RSA 4096-bit w/ SHA256 hash. Let me know if there are any gotchas with the params used to generate a cert.

10

It might be worth trying to generate your own. If you can export the existing cert and private key it shouldn’t hurt anything to try.

I don’t own a Synology so I can’t say, but it seems odd that you can’t even directly trust the certificate.

11

Ok I’m gonna generate a new custom cert (still self-signed). Synology is pretty flexible and lets me use that cert for the WebDAV service. Will see if it helps.

12

Ok I made a custom self-signed cert, imported into my Synology NAS and bound it to the WebDAV service.

It didn’t help. I still get “The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel” at the END of the backup cycle.

I tried trusting just the cert fingerprint, and tried allowing all certs. Both have the same result.

13

I might be misremembering a different issue but could this be related to out of date cert info like we’ve previously seen with mono?

14

There is a known problem in the beta (fixed in latest canary) that the tray-icon runs in the same process as the backup jobs, and uses the same methods. This means that each time the tray-icon performs a request to see if the icon should be updated, it will reset the ssl settings for the running backup.

You can either start the trayicon itself with --accept-any-ssl-certificate and also set the job up with this, or try the latest canary build.

2 Likes
15

Great, thanks for the info!

16

It worked! I was even able to use the option to accept just a specific certificate hash.

17

Erm…was it the --accept-any-ssl-certificate parameter, upgrading to the latest canary (2.0.2.10), or both that worked for you? :slight_smile:

18

I’m still running 2.0.2.1_beta_2017-08-01 on all the machines. I added the --accept-specified-ssl-hash option to the backup set definition and also to the command line for the initial launch of the GUI process. It was that second part that solved it…

1 Like