I am testing a lot of features on UrBackup and one I have not seen information about is how to setup HTTPS on a Windows-based machine. Plenty of documentation if you’re running this on a Linux box or maybe I missed it in the manual. If someone has done this, could we get some idea of how to go about this. It’s not clear to me what engine (web engine) is actually driving the windows-based version of UrBackup. Apache/Light – just not sure. Thanks in advance!
We would use a reverse proxy for this, ive not tested this, so experience i believe any external clients need to look at the correct port (55415?) but for the web interface its 55414, so you would need a HTTPS off-loaded (a reverse proxy) which will allow the remote browser to secure connection to the HTTPS engine, which will then proxy over to the real server on port 55414. The client will still talk directly to the server, so the https would only be for the web traffic, unless any corrects me on this?
We do the above with many internal servers with out issue, not tested it with UrBackup though
My confusion here is partially due to my lack of specific experience setting up a reverse proxy situation. From my limited understanding on this topic, setting it up would require me to edit configs based on the WebGUI’s server of choice (Apache, etc.). Since I’m not sure which one is built into the WebGUI in the .EXE Windows version of the software, I don’t know how to proceed.
Generally when doing this the reverse proxy is not on the same PC, as this uses port 55414 it could be, the issue you have it getting the certificate, assuming you can arrange that, you would load Apache HTTP (which can be done on Windows), create a virtual host inside apache, then list a reverse proxy back to http://127.0.0.1:55414 for all directories (/*) so any request will result in Apache requesting the resource from http://127.0.0.1:55414.
Apache has the SSL and handshakes to the browser so the secure connection is between the browser and Apache, ANY URL is then taken by Apache and requested from http://127.0.0.1:55414 and passed back to the browser through apache over the https channel.
Its not a simple process, most places will have a single Apache server hosting many virtual DNS names and collecting SSL certificates for all of them with a reverse proxy back to the real server inside the firewall. However this puts a huge load on to the Apache server for what appears to be a simple setup.
I think your have more of an issue with the SSL as Chrome no longer supports self signed certificates your need to either buy one or use a service to get one and they require a outward facing DNS name that works to authenticate that the SSL you want is actually real. The ones wanting to confirm its real normally need to see both port 80 and 443 pushed back to the same server so you need a static IP address…
If this is for a LAN your better to just use VPN to access the web server, it negates all the reverse proxy and SSL headaches of the above.