Duplicacy Web should reload SSL certificates when they change

Duplicacy Web 1.5.0 adds the ability to provide your own SSL certificates. It only loads that certificate on startup. This means that if the certificate changes, it will require a restart to actually use the new cert. It’d be nice if DW would periodically check the certificate files and reload them if they have changed.

I doubt periodic check is better and relying on inotify is dangerous because it’s broken on many platforms and old docker versions.

Instead whichever script updates the certificates should send hangup signal to the duplicacy_web process or just simply restart it. It’s a once-every-few-years deal (what is max certificate validity today? 823 days IIRC) and hardly justifies periodic polling that may break other features. Like drive hibernation.

Just my 2 cents.

Let’s Encrypt certs (free!) are valid for 90 days and are typically renewed at least 30 days early. It is meant to be an automated process.

Also, HUP just takes down the process. If it or another signal triggered the application to rescan the configuration files (including the certificate) I could use that, as long as it didn’t require re-entering the password. That is the critical step I’m trying to avoid.

In my case, the drives already never spin down. If the periodic check was configurable though, it’d be easy to co-ordinate checking at an appropriate time. Again, in my case at least, the certificate renewal is run by cron at the same time each day so checking the cert for changes a few minutes after that would be good enough.

But, yeah, I understand this isn’t something everyone would need.

My personal pet peeve note on seemingly omnipresent urge to use LE in odd cases like this one where it has no business being:

Let’s encrypt certificates are useful for (that’s the specific design goal) web services that are accessible via FQDN externally, to the general public. Duplicacy UI is not such service. In fact, it’s exact opposite: available in the lan at most and to very few people. Most common usecase is accessing ui running in a lan host, accessible by often just one person.

LE does not support subject names other than verifiable external FQDNs. This is not what people use in the lan. MDNS named, host names, ip addresses are not supported.

LE is therefore is a very ill-suited certificate source for duplicacy.

Instead, you can issue certificate yourself (for free) of any validity you like for any subject names you need, and not bring unnecessary external dependency, needless complexity, and avoid frequent updates; all while getting more user-friendly solution.

Hmm. This is something that can be handled I guess — for cases when config needs to be reread

Meh, to each their own.

LE does support DNS based certificate renewals, so it’s very easy to generate a cert for a domain that is not externally available. And even if the web interface doesn’t need SSL, it certainly doesn’t hurt and rounds out the rest of the services that I’m running without requiring a wrapper service to provide it. Otherwise, I’d think the feature request would be to remove SSL support entirely to keep things simple. I suppose that’d be the other option for my case. Drop SSL support from the web process and provide it via nginx. An option, but less than ideal.