--accept-specified-ssl-hash

I got a shiny new NAS to place at a friend’s office for a local but offsite option. It’s got, by default, a self-signed certificate. Which might be OK for my needs. But when I set it up as a WebDAV destination and tried to test it, I got a really verbose error message that said, in part:

The server certificate had the error RemoteCertificateChainErrors and the
hash <hash value> If you trust this certificate, use the commandline option
--accept-specified-ssl-hash=<hash value> to accept the server certificate 
anyway. 

So that’s fine with me… but I cannot get it to work.

  1. When I bring up the advanced options, I have two of each option under the group “Configure http requests”
  2. Choosing either --accept-specified-ssl-hash option and filling in the hash value has no effect.

I noticed some others had issues in this area that were a conflict with the tray-icon process, but I am not using the tray icon at all.

Running 2.0.2.1_beta_2017-08-01 on Ubuntu 16.04

Have you gotten any WebDAV based backup jobs to work elsewhere or is this your first one? I’m asking because I wonder if it’s a mono / SSL certificate issue…

If it is a cert problem, some suggested solutions can be found at SSL TLS support in Mono · duplicati/duplicati Wiki · GitHub.

That page is basically various system versions of installing ca-certificates-mono and/or updating existing certs (such as with sudo cert-sync /etc/pki/tls/certs/ca-bundle.crt).

OP writes that it is a self-signed certificate, so getting the real certificates working will not fix the problem.

Are you sure that the hash value does not change? Also can you try exporting as a commandline, and see if the exported commandline looks correct.

There is a debugging option called --accept-any-ssl-certificate that you can experiment with, but I suggest not using it for anything real, as it undermines the security of the certificate system (i.e. allows man-in-the-middle attacks).

Thanks for clarifying - for some reason I had it in my head that a self-signed cert could still have a public Certificate Authority. Oops. :blush:

So on my next attempt, and a reload or two of the UI, I got the --accept-specified-ssl-hash to work. And BTW the UI stopped showing me doubles of the “Configure HTTP Request” options.

Now, on doing a test connection, I get:

System.Net.WebException: Error: TrustFailure (One or more errors occurred.) ---> System.AggregateException: One or more errors occurred. ---> System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception. ---> Mono.Btls.MonoBtlsException: Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
  at /build/mono-5.4.0.201/external/boringssl/ssl/handshake_client.c:1132
  at Mono.Btls.MonoBtlsContext.ProcessHandshake () [0x00038] in <8a8abae728c244359683ef777047ab9e>:0 
  at Mono.Net.Security.MobileAuthenticatedStream.ProcessHandshake (Mono.Net.Security.AsyncOperationStatus status) [0x0003c] in <8a8abae728c244359683ef777047ab9e>:0 
  at (wrapper remoting-invoke-with-check) Mono.Net.Security.MobileAuthenticatedStream:ProcessHandshake (Mono.Net.Security.AsyncOperationStatus)
  at Mono.Net.Security.AsyncHandshakeRequest.Run (Mono.Net.Security.AsyncOperationStatus status) [0x00006] in <8a8abae728c244359683ef777047ab9e>:0 
  at Mono.Net.Security.AsyncProtocolRequest+<ProcessOperation>d__24.MoveNext () [0x000ff] in <8a8abae728c244359683ef777047ab9e>:0 
--- End of stack trace from previous location where exception was thrown ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <9790d962aaad40deb63d33029ba0d2f6>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess (System.Threading.Tasks.Task task) [0x0003e] in <9790d962aaad40deb63d33029ba0d2f6>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification (System.Threading.Tasks.Task task) [0x00028] in <9790d962aaad40deb63d33029ba0d2f6>:0 
  at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd (System.Threading.Tasks.Task task) [0x00008] in <9790d962aaad40deb63d33029ba0d2f6>:0 
  at System.Runtime.CompilerServices.ConfiguredTaskAwaitable+ConfiguredTaskAwaiter.GetResult () [0x00000] in <9790d962aaad40deb63d33029ba0d2f6>:0 
  at Mono.Net.Security.AsyncProtocolRequest+<StartOperation>d__23.MoveNext () [0x0008b] in <8a8abae728c244359683ef777047ab9e>:0 
   --- End of inner exception stack trace ---
  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw () [0x0000c] in <9790d962aaad40deb63d33029ba0d2f6>:0 
  at Mono.Net.Security.MobileAuthenticatedStream+<ProcessAuthentication>d__47.MoveNext () [0x00254] in <8a8abae728c244359683ef777047ab9e>:0 
   --- End of inner exception stack trace ---
  at System.Threading.Tasks.Task.ThrowIfExceptional (System.Boolean includeTaskCanceledExceptions) [0x00011] in <9790d962aaad40deb63d33029ba0d2f6>:0 
  at System.Threading.Tasks.Task.Wait (System.Int32 millisecondsTimeout, System.Threading.CancellationToken cancellationToken) [0x00043] in <9790d962aaad40deb63d33029ba0d2f6>:0 
  at System.Threading.Tasks.Task.Wait () [0x00000] in <9790d962aaad40deb63d33029ba0d2f6>:0 
  at Mono.Net.Security.MobileAuthenticatedStream.AuthenticateAsClient (System.String targetHost, System.Security.Cryptography.X509Certificates.X509CertificateCollection clientCertificates, System.Security.Authentication.SslProtocols enabledSslProtocols, System.Boolean checkCertificateRevocation) [0x0000d] in <8a8abae728c244359683ef777047ab9e>:0 
  at Mono.Net.Security.MonoTlsStream.CreateStream (System.Byte[] buffer) [0x0007b] in <8a8abae728c244359683ef777047ab9e>:0 
  at System.Net.WebConnection.CreateStream (System.Net.HttpWebRequest request) [0x00073] in <8a8abae728c244359683ef777047ab9e>:0 
   --- End of inner exception stack trace ---
  at Duplicati.Library.Utility.AsyncHttpRequest+AsyncWrapper.GetResponseOrStream () [0x0004d] in <1cb5198b00f34ae59d97ee7fe7a3a16c>:0 
  at Duplicati.Library.Utility.AsyncHttpRequest.GetResponse () [0x00044] in <1cb5198b00f34ae59d97ee7fe7a3a16c>:0 
  at Duplicati.Library.Backend.WEBDAV.CreateFolder () [0x00022] in <fce6c1cbe34c4991be07b95fa0e7a551>:0 
  at Duplicati.Server.WebServer.RESTMethods.RemoteOperation.CreateFolder (System.String uri, Duplicati.Server.WebServer.RESTMethods.RequestInfo info) [0x0000c] in <a6c0c2089b9a44ec9be5057a44f12116>:0 
  at Duplicati.Server.WebServer.RESTMethods.RemoteOperation.POST (System.String key, Duplicati.Server.WebServer.RESTMethods.RequestInfo info) [0x0007f] in <a6c0c2089b9a44ec9be5057a44f12116>:0 
  at Duplicati.Server.WebServer.RESTHandler.DoProcess (Duplicati.Server.WebServer.RESTMethods.RequestInfo info, System.String method, System.String module, System.String key) [0x0026e] in <a6c0c2089b9a44ec9be5057a44f12116>:0 

So it looks like I am not really fully accepting the QNap cert, but more like shoving it a little further down Mono’s throat until it vomits it back.

Yes, that is a problem inside Mono. It really should present the certificate to Duplicati so it can accept it, but it looks like it just throws the error anyway.

If you can get it to work with --accept-any-ssl-certificate, then it is likely a bug in Duplicati.

If not, then it is an issue in Mono. In that case you may be able to work around it by setting the environment variable MONO_TLS_PROVIDER=legacy before starting Duplicati.

Nope - also fails with accept-any.

I will update mono and set the legacy ssl provider variable and try again

FYI - it appears the duplicate “Configure http requests” advanced options has been addressed.