Http send report errors / duplicati-monitoring

The solution for the official Duplicati Docker image is the same as posted above for Debian. You want to remove this file from within the container:

/usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt
1 Like

Great its working now on my Docker instances! Thank you guys!

The only one still not working is the Duplicati plugin on my TrueNAS. Since this is FreeBSD based, the way certificates are managed slightly differs and I did not succeed.

Answering to myself: actually the solution is quite simple:

1 Like

I started receiving this same error today when trying to connect to Backblaze B2 as the backup target.

The instructions by @hairlesshobo worked to fix the issue.

Thanks, @hairlesshobo!

Hi, I also get a cert error when trying to run my desktop backups.

System.Net.WebException: Error: TrustFailure (Authentication failed, see inner exception.) —> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception. —> Mono.Btls.MonoBtlsException: Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

Thing is I am on Manjaro and since it’s not Debian based I can’t apply the above workarounds. I also couldn’t find anything tangible to do manually online, so I am at a bit of a loss here, and I don’t want to try taking risky initiatives since this is my daily driver machine.

Does anyone happen to know what I could do/read?

I have a fully updated system. Backups were fine yesterday.

There’s a link in Duplicati issue Mono.Btls.MonoBtlsException: Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED #4075 giving Arch advice.

1 Like

Oh, I checked there but it wasn’t mentioned yet :stuck_out_tongue: Thank you @ts678 for the help, it worked.

For anyone else interested, the commands for Arch mentioned in the link are those below, that should be done as root:

# blacklist the expired certificate
cp /etc/ssl/certs/DST_Root_CA_X3.pem /etc/ca-certificates/trust-source/blocklist/

# update the system wide trust store
update-ca-trust

# and finally sync the system trust store to mono
cert-sync /etc/ssl/certs/ca-certificates.crt

Edit: You may need to run the last command twice.

1 Like

I’ve been having an issue for the last week, but I’m not sure if it is the same one from this thread or not.

Environment:

  • 3 systems running Fedora 34, Duplicati - 2.0.6.100_canary_2021-08-11, mono 6.12.0-4
  • 1 system running Windows 10, Duplicati - 2.0.6.100_canary_2021-08-11
  • All using backblaze for storage.

2 Fedora systems started failing Tuesday, November 30, the other Fedora system says it succeeded on the 30th, but then has failed since December 1. The Windows 10
system is not reporting any issues.

The error reported is:

System.AggregateException: One or more errors occurred. (Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
at /builddir/build/BUILD/mono-6.12.0.122/external/boringssl/ssl/handshake_client.c:1132 (Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED
[repeated multiples times - I can provide the full trace if desired]

I have attempted to blacklist the DST certificate - no change, so either it wasn’t the issue, or the attempt failed. Also, note that backups have been working through November so if the issue was the certificate expired in October, would this even be applicable?

I have also tried playing with forcing SSL3, TLS1.1, etc. (not saying I tried all of the them) - no help.

I tried “update-crypto-policies --set LEGACY” followed by a reboot - no help.

Any suggestions for troubleshooting this?

Does the above RHEL/CentOS article help any? Is that how you blacklisted the certificate?

Do you see web page data or an error if you run this test, based on mono-project.com test:

csharp -e ‘new System.Net.WebClient ().DownloadString (“https://api.backblazeb2.com”)’

You could also ask what Backblaze support has to say. Above-named site (one of many you may trip on) has a Let’s Encrypt certificate with trouble-for-mono default chain, valid from 30 Nov 2021 02:22:14 UTC.

I did a “update-ca-trust extract”, extracted the “DST Root CA X3” section to a file in /etc/pki/ca-trust/source/blacklist, and then ran update-ca-trust to rebuild the cert db (or whatever it does). The output certainly appears to be honoring the blacklist - I get multiple lines saying “p11-kit: overriding trust for anchor in blacklist: DST.crt”. I also ran several cert-sync commands against files in the /etc/pki directory. To be extra safe, I then rebooted.

No web page data, no error. It just returns to the command prompt. Also, firefox has no trouble with the backblaze url. I will take a look at the mono-project link provided to see if it provides any further insight.

So you are saying that instead of a systemic issue, this would be specific to mono? If so I need to back-out the blacklist change. The Nov 30 date would be when 2 out of 3 systems started failing. Unless something was cached, I’m not sure why the 3rd took an extra 24 hours to fail.

Thanks very much for the suggestions!

The “csharp -e ‘new System.Net.WebClient ().DownloadString (“https://www.nuget.org”)’” test from the mono-project.com test link provides the expected html.

As stated previously, the " csharp -e ‘new System.Net.WebClient ().DownloadString (“https://api.backblazeb2.com”)’" test results in no output and no error.

I believe I have found a solution/workaround! Testing now, and will post details once I have confirmed.

Environment:

  • Fedora 34
  • Duplicati - 2.0.6.100_canary_2021-08-11
  • mono 6.12.0-4

Issue:
Starting December 1, 2021, Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED

Solution/Workaround:

And then as root:

  • copy file to /etc/pki/ca-trust/source/anchors
  • update-ca-trust
  • cert-sync certificate-file
  • systemctl stop duplicati
  • systemctl start duplicati
2 Likes

Let’s Encrypt Chain of Trust has that link described as the ISRG Root X1 self-signed version.
Certificate Compatibility under Platforms that trust ISRG Root X1 doesn’t list Fedora, but might not be an exhaustive list. Regardless, thanks for finding and documenting the addition that solved the issue for you.

I wish this was included in the docker image so that i didnt have to do it manually!

I tried this solution in Centos 8 and no luck, the CERTIFICATE_VERIFY_FAILED error persists. Duplicati can’t get past the “Listing remote files” step.

Anyone find a solution for Centos 8 or its successors like Rocky or Alma?

I too was having the same issue, albeit on an Arch Linux system, and I found a solution that I documented here

Hope this helps

1 Like

Apparently this work-around has to be re-applied after upgrading from Fedora 34 to Fedora 35.

  • Fedora 35
  • Duplicati - 2.0.6.100_canary_2021-08-11
  • mono 6.12.0-5

Github can’t save me but u can ,thank u so so very much! :crazy_face:

In case someone with QNAP NAS is still suffering from this issue. Here is a short instruction how to fix:

  1. Enable SSH/SFTP (if not already open) through Qnap web portal.
  2. Connect with SFTP client (for example Filezilla)
  3. Go to path: /share/CE_CACHEDEV1_DATA/.qpkg/Qmono
  4. Edit file “ca-certificates.crt”
  5. Remove certificate rows related to DST ROOT CA X3
  6. Save file
  7. Stop and start Mono and Duplicati services through Qnap web portal.

Hope this helps.

1 Like