2.0.3.7 on Mac: Missing certificates

I believe the existing message is caused by mono itself and not any specific part of the application, and I don’t think we can modify it.

But we can probably make a check for it and provide that information in a separate warning. Where would that check make sense to run? before starting a backup?

Unless we’re talking about different messages, it’s our text:


I should mention that for me, adding the certs resolved the “No certificates found” warning, but has NOT done anything with the “Value does not fall within the expected range” SshNet error.

So those may not be as related as I assumed they were previously.

Oh, my mistake.

I don’t think they’re related. My cert warning did not cause any actual issues. I just got a warning on every backup.

Do you think the multi-command string I proposed is too long? I’m worried the extra steps of manually downloading (and finding) the certs will be a turn-off for some users.

Also, do you think --user should NOT be used (--user will populate the per-user store in the user’s home directory, instead of the system-wide store.)

Hmm, I did it without --user

I basically did

wget https://curl.haxx.se/ca/cacert.pem; cert-sync cacert.pem; rm -f cacert.pem # For MacOS

I like yours better and have put in a PR for it. :slight_smile:
https://github.com/duplicati/duplicati/compare/master...JonMikelV-certUpdate-MacOS?quick_pull=1

There might be a typo

https://curl.haxx.se/ca/cacert.pem; cert-sync cacert.pem; rm -f cacert.pem # For MacOS missing the wget :slight_smile:

@JonMikelV’s changes have been merged into master now Merge pull request #3324 from duplicati/JonMikelV-certUpdate-MacOS · duplicati/duplicati@c5e25e7 · GitHub
Should show up in next release.

That may not be a bad thing… I just tested on a Mac I support (10.13.5 High Sierra) and it doesn’t seem to have wget but it does have curl.

Maybe it would be “safer” to use:
curl --remote-name https://curl.haxx.se/ca/cacert.pem; cert-sync --user cacert.pem; rm -f cacert.pem # For MacOS

Instead of:
wget https://curl.haxx.se/ca/cacert.pem; cert-sync --user cacert.pem; rm -f cacert.pem # For MacOS


Actually, I was thinking - why would we NOT want Duplicati to do this? By having a “fetch latest certificates” button (maybe under global settings) Duplicati could do the fetch and cert-sync which would ensure thy are applied under the correct account.

Hmm, changing to curl might be safe. I must admit it never occurred to me it wouldn’t be on a modern UNIX system (other than small containers).

Building it into Duplicati as a command might be a good idea, making it simpler to resolve for the end user.

Oddly, I’m finding that I have the certs added both for the regular user account and root (which is what the MacOS daemon is using) and I’m still getting the warnings.

Is it possible mono is running under yet a different account?

Running ps aux | grep duplicati should reveal the user that Duplicati is running under on any UNIX system.

# ps aux | grep duplicati
rune             72887   0.0  0.0  4276968   1024 s001  S+   11:44PM   0:00.00 grep --color duplicati
rune             67054   0.0  0.1  4394052  18824   ??  S    Sun09PM   0:06.46 /System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python /Users/rune/git/duplicati/Duplicati/GUI/Duplicati.GUI.TrayIcon/bin/Debug/OSXTrayHost/osx-trayicon-rumps.py
rune             67050   0.0  0.3  4528480  47972   ??  S    Sun09PM   0:55.64 /Library/Frameworks/Mono.framework/Versions/5.10.1/bin/mono --debug --debugger-agent=transport=dt_socket,address=127.0.0.1:59003 /Users/rune/git/duplicati/Duplicati/GUI/Duplicati.GUI.TrayIcon/bin/Debug/Duplicati.GUI.TrayIcon.exe

On my system Importing the certificates under the correct user worked for both my own user and for root.

For the record, I found that when running Duplicati as daemon / service on MacOS (meaning it was running under root) I needed to run:

sudo -i #interactive login so all following commands execute as root
curl -O https://curl.haxx.se/ca/cacert.pem; cert-sync --user cacert.pem; rm cacert.pem #for MacOS

Makes sense. Each delimiter ; will start a new command without sudo applied.
Alternatively you can also change user with sudo su, which I usually do when I want to make sure it runs everything under root.

Sounds like maybe my issue too, however the fixes seem to go over my head.
Is it possible for a non technical Mac user to resolve the missing SSL cert issue?
I did get Duplicati - 2.0.4.5 working to backup files to Amazon drive, but somewhere along the way, maybe during the OS upgrade to 10.14.3 I started getting the SSL warnings. Any help is greatly appreciated.

This fix doesn’t work for me… it shows 135 certificates trusted, yet Duplicati still throws error… running duplicati as a non administrative user but installed certificates as root

Hi @esaldana and @Jeremy_Larose, welcome to the forum!

Not that I know of - but I’m not a Mac expert.

By default sudo runs as root. To install the certificates for a different user try the above command but start it with sudo -u [my-non-admin-user] -i

Thanks, yes, its profile specific, so to deploy it to unknown users, a LaunchAgent would have to be used

Ah, I get it now.

You could use a run-script-before to do it…

Yes, if you run as a LaunchDaemon you are running as user root with home dir /var/root and the certs are installed by cert-sync in ~/.config/.mono

Running this on every job launch is overdoing it. The smoothest way forward would be to have /Applications/Duplicati.app/Contents/MacOS/duplicati-server do this on launch when needed, but that is of course a side effect (from Duplicati on mono) so a bad programming style, unless it becomes a Duplicati flag (–update-mono-certs={atlaunch,eachjob,whenneeded}, the latter reacting to the warning from Mono).

The cleanest/simplest option would probably be to offer a cert-update script and have that run as a regular job (monthly) via /etc/periodic