The duplicati-entry is:
–send-mail-url=smtp://user123456.kasserver.com:587/?starttls=always
Duplicati don’t send a Mail and shows th following error:
2024-01-25 18:41:13 +01 - [Warning-Duplicati.Library.Modules.Builtin.ReportHelper-ReportSubmitError]: Fehler beim Senden der Nachricht: MailKit.Security.SslHandshakeException: An error occurred while attempting to establish an SSL or TLS connection. The SSL certificate presented by the server is not trusted by the system for one or more of the following reasons: 1. The server is using a self-signed certificate which cannot be verified. 2. The local system is missing a Root or Intermediate certificate needed to verify the server's certificate. 3. The certificate presented by the server is expired or invalid. See https://github.com/jstedfast/MailKit/blob/master/FAQ.md#InvalidSslCertificate for possible solutions. --> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception. --> Mono.Btls.MonoBtlsException: Ssl error:1000007d:SSL routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED at /wrkdirs/usr/ports/lang/mono6.8/work/mono-6.8.0.123/external/boringssl/ssl/handshake_client.c:1132
this can’t be tested by an external person since the mail server is specific for each user, so it can’t be accessed from the public Internet. This is probably the reason why your provider is using a self-signed certificate (even if it’s a bad reason, they should use a wildcard public certificate instead, it would cost them 0 euros with Let’sEncrypt and solve your problem instantly…)
You could possibly solve it by getting the self-signed certificate file using openssl, then adding it to the Mono certificate store using certmgr or cert-sync. Even if you go this way, don’t hesitate to educate your provider on the proper use of Internet standards.
is about 4 years old. You could try installing per Duplicati manual, assisted by Mono Project if needed.
FAQ: Security talks about cert-sync (syncs from system certificate store, but is that up to date?) and mozroots which just grabs information from Mozilla’s site, bypassing any cert issues in system’s store.
Not knowing your SMTP server prevents us from checking its certificate use, but STARTTLS makes job harder because it happens in the middle of a TCP connection, which makes it hard to use testing tools.
If this is TrueNAS, TrueCharts has Duplicati although I think some people don’t want to use TrueCharts. Getting a current mono on FreeBSD has been an ongoing struggle, but that might not be the issue here.
The OP could at least report the result of this command with the problematic server, since in this case, it’s not possible for us to test because each customer has their own mail server address as a subdomain for kasserver.com, this base server address (kasserver.com) don’t listen on the 587 port.
-starttls protocol
send the protocol-specific message(s) to switch to TLS for communication. protocol is a keyword for the intended protocol. Currently, the only supported keywords are “smtp”, “pop3”, “imap”, and “ftp”.
It’s on at least 80 and 443, so is probably a web server. The SMTP server for at least some users is at mx.kasserver.com (user would have to confirm with nslookup as shown above), and this answers as:
Certificate chain
0 s:CN = *.kasserver.com
i:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Dec 18 00:00:00 2023 GMT; NotAfter: Jan 17 23:59:59 2025 GMT
1 s:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
v:NotBefore: Nov 2 00:00:00 2018 GMT; NotAfter: Dec 31 23:59:59 2030 GMT
2 s:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
i:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
v:NotBefore: Mar 12 00:00:00 2019 GMT; NotAfter: Dec 31 23:59:59 2028 GMT
but we don’t know if this is the relevant server. Regardless, this one doesn’t have the Lets Encrypt bug.