A System.Net.WebException: Error: TrustFailure error occurs

@rmsehfdoal is this possible? It will probably also get Linux security fixes you should install.

If you must stay on CentOS 6 for a bit, does certificate issue cause issues besides log noise?
There are worse things to lose than Duplicati updates, and cert issues can have wider effects.

Which CentOS 6.x dot-release? 6.0 in 2011 may still be missing the ISRG Root X1 from 2015.
I’m thinking it might be time to use higher-level tools in diagnostics, for example something like:

$ certmgr -list -certificate -m Trust | egrep --context 2 'ISRG Root X1|DST Root CA X3'
Self-signed X.509 v3 Certificate
  Serial Number: 008B8263BBE0634459E340D2B0CF108200
  Issuer Name:   C=US, O=Internet Security Research Group, CN=ISRG Root X1
  Subject Name:  C=US, O=Internet Security Research Group, CN=ISRG Root X1
  Valid From:    6/4/2015 11:04:38 AM
  Valid Until:   6/4/2035 11:04:38 AM
$ 

“seems” like it should work, however if this also shows up then mono will likely say TrustFailure:

Self-signed X.509 v3 Certificate
  Serial Number: 6B40F82E86393089BA27A3D680B0AF44
  Issuer Name:   O=Digital Signature Trust Co., CN=DST Root CA X3
  Subject Name:  O=Digital Signature Trust Co., CN=DST Root CA X3
  Valid From:    9/30/2000 9:12:19 PM
  Valid Until:   9/30/2021 2:01:15 PM

EDIT:

RHEL/CentOS 6 OpenSSL client compatibility after DST Root CA X3 expiration has a big discussion, including how to get an OpenSSL that’s even more ancient than mono’s BoringSSL to work correctly.
Solution seems to be that one can’t, however one can try to rebuild a newer OpenSSL on their own…

Duplicati doesn’t require OpenSSL to work (but other things on the obsolete system might need that).
One novel but kind of ugly workaround here is to do a sed edit to extend the 9/30/2021 expiration date.