Any updates on this one?
Sorry I didn’t do it for 1.2.0/1.2.1. I’ve added it to Roadmap for the web GUI to make sure it will be included in the next version.
4 Likes
Eagerly waiting for this support to come as well.
1 Like
Any update on this? I generate wildcard SSL certs outside and would be nice to expose something in the web UI to point to the cert.
Version 1.5.0 supports custom certificates. You’ll need to create 2 files under ~/.duplicacy-web/certs: domain.crt contains the full chain certificates and domain.key is the private key ( replace domain with the actual domain name).
1 Like
Hi, I am interested in running Duplicacy web gui using ssl on my lan, and believe that this is the way. I’m using a docker within Unraid. That said, I’m not extremely technical and was having some issues understanding how to implement this. Would it be possible to break it down as you might for a 5 year old? 
The first thing I ran into is that my docker install has a config folder that looks like below. So where would I place the two files? And then if you might guide me in a little detail on creating those files, I would very much appreciate it. I think I can get as far as creating a private and public key, but that’s probably the extent of it. 
As well, I’m wondering how to complete the settings form with https address and domain. Would the address be just :443 and the domain be localservername.local? Sorry to ask you these tedious questions and I appreciate your help.
If you are using this container, https://hub.docker.com/r/saspus/duplicacy-web, you would create the “certs” folder in the config folder, the one open on your screenshot.
You might want to review this: Creating Self-Signed Certificate Authority to issue SSL certificates using Certificate Assistant on macOS | Trinkets, Odds, and Ends. If you use macOS you can just follow the guide, if not – you can use the packages like easyRSA to get this configured as described.
Thanks for jumping in. Yes, I’m using your docker, so thank you for that too! So I created the files and placed them in a newly created certs folder. I then restarted the app. But the Web UI then resolved to the base server/unraid login page. So I then deleted the certs folder and restarted the app again and it still does the same thing, even after clearing the browser cache. I also tried adding :3875 to the server url but that still did not work. Here is what I see in the logs “Failed to get the value from the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: exec: “dbus-launch”: executable file not found in $PATH”
I think the issues may be in the dns names and IP address I chose for the certificate? I just used the root server name and IP, which I guess would conflict with unraid? In any case, I would say that at this point I’m ready to take my chances on an unsecured duplicacy, as I’ve already entered all of the critical infop into the app anyway. What I would like to do though is get it back to the default state where i can login, without losing my setup and having to reinstall. Any guidance on that would be appreciated.
I think not all ports work. Try 8080
Okay, I changed the https address in the settings file to both :447 and :8080 with no success. The UI defaults to the root IP for the server. I think the issue is with the domain and IP address values I am using in both the cert, and in the settings page. Can you give me explicit guidance around what those values are supposed to look like? Thx.
To give you a little more detail, this is what I used in the cert:
dnsname: duplicacy.servername.local
IP Address: A random IP trhat I noticed was unused on my network
Settings File:
https Address: I tried these: :443, :447, :8080
https Domain: duplicacy.servername.local
Does this look correct?
This is not much to go from to advise anything.
Here is what I woudl check:
- verify that settings.json contains correct configuration for https
- verify that the duplciacy actualy starts https server and loads certificates, in the log
- open shell in the container and confirm it’s listening on the port you expect it to
- confirm you have configured port forwarding on docker
- confirm your host does not listen on those ports and that port forwarding succeeded.
- without using browser, attempt to curl data from that IP and port, where you expect duplciacy to respond.
It’s not a good idea to hardcode IP in the certificate. It does not cause your issue, but it’s not a good idea to do, and definitely don’t provide IP of a different host.
Does duplicacy.servername.local resolve correctly to the IP that has port open that forwards to duplicacy? What happens when in the browser you go to http://duplicacy.servername.local:8080?
BTW, .local domain is managed by zeroconf/mDNS; avoid re-using .local domains if you ever going to have mDNS (and with 99% probability you already have – most modern devices run it by default)
This is great, thank you for this. I think at this point I’m beyond my level (very low!), and will have to default back to an insecure connection, unfortunately. I’m not sure if there’s a way to code https into the app by default, but that would be really amazing. Thank you for all your support!
Consider using caddy in referse proxy mode, to provide HTTPS for any HTTP app: Caddy Reverse Proxy - User Customizations - Unraid
Or consider using Clouflare Zero Trust Access | Zero Trust Network Access platform to access the internal app behind some authentication. Both are free, and significantly easier to configure compared to managing certificates, ports, and all that…
Check the log file logs/duplicacy_web.log which should contain this line:
Starting the web server at https://HTTPS_ADDRESS using certificates for HTTPS_DOMAIN
where HTTPS_ADDRESS and HTTPS_DOMAIN are specified in the Setting page.
The two files domain.crt and domain.key – you’ll need to replace domain with the actual domain, i.e., HTTPS_DOMAIN.
Thank you @gchen and @saspus. I really appreciate the support, but the options you’ve suggested are unfortunately beyond me. Something like this might seem straightforward to you, but makes my head really hurt. I can handle step by step directions, primarily using gui’s, that don’t require too much networking. Hopefully nothing on my lan is sniffing traffic! Keep up the great work, and hopefully one day https can be offered with a click by every app, as it is with unraid itself.
Hi again. Since I’m not technical enough to secure Duplicacy with SSL, on my Unraid server, I’m wondering what my security risks are and whether I need to find a different backup solution? I’ve already setup my B2 bucket, input an encryption key, and backed up data to B2, over http. Are my threats internal to my own network only? Or could my data be intercepted over the public web? Given you aren’t aware of all my devices and network architecture I’m just looking for general hypothetical and risk levels. I have no ports open on my router. Thank you!
Someone in the lan can listen to your communication with duplicacy_web UI and intercept the ui password, and be able to do everything you can do in Duplicacy UI.
I’d argue that if a bad actor is already in your lan, duplicacy password is the least of your worries.
Yes.
Data is encrypted in flight and at test.
So I would not worry.
Btw have you considered ssh tunneling?
It’s pretty easy. You have duplicacy-web listen on a loop back interface only (127.0.0.1), instead of all interfaces (0.0.0.0). This will make it impossible to connect to its UI except from unraid server itself.
Next you enable ssh tunneling on your unraid server. I don’t know if there is UI for that, but I you should end up with AllowTcpForwarding yes in sshd_config on your unraid server and restart sshd.
Then to connect to duplicacy you first start the tunneling session for traffic on port 3875 on your machine:
ssh -N -L 3875:127.0.0.1:3875 username@unraid_ip
And then connect to port 3875 on the localhost to reach the ui. http://localhost:3875/
This way communication between you and duplicacy UI will be encrypted via SSH.
Again, in my opinion, this is completely unnecessary, if the threat is in your LAN the most important battle is already lost. I myself have a bunch of internal sevices over plain http in the lan.
Tangentially, If you concern is that someone getting access to duplicacy can mess up backup on B2 (regardless of whether ui communication is encrypted) — you can give Duplicacy b2 credentials that only allow backup but not delete. Prune won’t work of course but this will as secure as it gets.
Thank you very much. I actually managed to setup a Cloudflare Tunnel, so I’ll just use Duplicacy over that from here on in. I used this video which simplifies things in case anyone else is interested. Thank you again for all your support!
1 Like
Very nice! I’m glad cloudflare tunnels work for you. I use it for. absolutely everything, even when I’m in the same lan. I’ve setup GitHub authentication and disabled all other modes of authentication to remove the choice dialog. Now I am asked to authenticate once per months, and I mess with my services from anywhere. It’s genius.
1 Like