ubuntu 16.04

Latest Beta release of Duplicati

Tried using accept-any-ssl-certificate advanced setting

Attempting to backup via FTP over TLS (NOTE: Windows Duplicate clients have successfully backed up to this FTP server over TLS)

Receiving the error:

Fatal error
System.AggregateException: One or more errors occurred. —> System.Security.Authentication.AuthenticationException: A call to SSPI failed, see inner exception. —> Mono.Btls.MonoBtlsException: Ssl error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE at /build/mono- at Mono.Btls.MonoBtlsContext.ProcessHandshake () [0x00038] in :0 at Mono.Net.Security.MobileAuthenticatedStream.ProcessHandshake (Mono.Net.Security.AsyncOperationStatus status) [0x0003c] in :0 at (wrapper remoting-invoke-with-check) Mono.Net.Security.MobileAuthenticatedStream:ProcessHandshake (Mono.Net.Security.AsyncOperationStatus)

Based on another mono SSL error I tried to set the following environment variable to no avail: MONO_TLS_PROVIDER=legacy

I’m wondering if there is an issue with mono expecting a specific SSL version. When I ran openssl s_client against the FTP server it gave:

Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384

Any thoughts?

Make sure you run the command to update mono’s trusted CA certificate store. I believe the command is “ca-certificates”. It exists in Ubuntu >=16.04.

I believe @hydrian is on the right track that this is a certificates issue, in which case you might want to take a look at this page (which covers various methods of installing ca-certificates-mono):

If that doesn’t help, make sure your certifications are up-to-date by running something like sudo cert-sync /etc/pki/tls/certs/ca-bundle.crt

And if that still doesn’t help, try telling your backup job to ONLY allow TLS 1.2 by setting the --allowed-ssl-versions command to Tls12:

--allowed-ssl-versions (default Ssl3, Tls, and SystemDefault)
This option changes the default SSL versions allowed. This is an advanced option and should only be used if you want to enhance security or work around an issue with a particular SSL protocol.

(By the way, I edited your post by adding “>” before your snippets to help them stand out a little better.)

I highly advise against enabling SSLv3. It is a very broken transport and has lots of know issues. Only use it if you absolutely have to.

Hmmm…I didn’t do anything to enabled it.

I haven’t checked the code yet, so I could be wrong, but when selecting the --allowed-ssl-versions in the GUi it comes in with Ssl3 already selected (along with Tls and Tls12). I assume SSLv3 is better than NO SSL, but I’m not sure what order the selected items are attempted.

For well known security reasons, SSLv3 should not be used unless expressly enabled. Even TLSv1(.0) is suspect but that’s a newer security development. The only real fully trusted transmission encrypted transport protocol there is TLSv1.2. I think if we enabled just TLSv1.2 there would be a mess because TLSv1 adoption is still quite high.

I’ll open a github issue on this.


Thank you both for the feedback. I failed to include critical information. The cert is self signed. But this would still be in the vein of ca-certs needing updated. I’ll be visiting the location soon and will try a few things. I imported the cert on the OS so cert-sync might do the job. I’ll report back.

Yep - that would make a difference. :slight_smile:

You might be interested in these parameters, if you’re not already using them…

Use this option to accept any server certificate, regardless of what errors it may have. Please use --accept-specified-ssl-hash instead, whenever possible.

If your server certificate is reported as invalid (eg. with self-signed certificates), you can supply the certificate hash to approve it anyway. The hash value must be entered in hex format without spaces. You can enter multiple hashes separated by commas.

@JonMikelV - Yes I have --accept-any-ssl-certificate set and I also imported it to the Ubuntu cert store.

The other day I was able to test a few more things when I visited. I ran
cert-sync ftp.crt
That worked by adding my .crt file, but to my shock it also removed some 148 trusted certs. I certainly didn’t pick up on that by the help text displayed by running cert-sync with no arguments. But no matter, the one I care about should now be trusted. I restarted but still received the same error.

I also set:
to both Tls12 and Ssl3 separately. Tls12 because that was displayed earlier with the openssl s_client command, and Ssl3 because the Mono error references that. Still gave the error.

Lastly I tried to test with:
# mono TlsTest.exe
But received the error:
FAILED: #-2146233067
System.NotSupportedException: Stream only works with HTTPS protocol
at TlsTest.GetStreamPage (System.String url) [0x0001c] in :0
at TlsTest.Main (System.String[] args) [0x0030a] in :0

I’m not sure what else to try at this point. I’m going to try to find a native Ubuntu utility to test the trusted status of the Cert, but I believe mono’s trust is what matters here.

It sounds like you’re doing all the right things - including ones that are beyond my skills, so unfortunately I don’t have anything else to offer. Hopefully @hydrian or @kenkendk might come up with some thoughts…

If you have --accept-any-ssl-certificate set, then the crash happens before calling Duplicati code. Based on the error message, I would guess that this happens somewhere in BoringTls, and it fails to understand the FTP server’s handshake messages.

It could still be a certificate issue, but I would guess that the fail happens before the certificate is validated. Not sure it helps you though.

I successfully connected to my FTP server from this Ubuntu box using lftp with no errors or certificate prompts, so I believe the OS trusts the cert just fine.

@kenkendk I found very little on BoringTls and mono while googling, but there were some mentions of problems with TLS 1.2 which my FTP site requires.

I have to ask, has anyone confirmed that Duplicati on Ubuntu handles FTP over TLS 1.2? If so, I’m not sure what would make my FTP server different. I’m not sure what’s next. I’ll try a pcap next time I’m on site to see if that identifies anything on the wire.