RfE: add a root-certificate to the hydrus api https process w/ user input fields for ip and dns names

[Chad90b]

current the hydrus api https checkbox makes hydrus spit out a self signed certificate.

i am requesting that this process also includes a root certificate that signs the standard api https certificate, and for the standard api https certificate to include san/subject alternate names to include by default 127.0.0.1 and localhost (ip.1 = 127.0.0.1, dns.1 = localhost) and for users to be able to input additional ip adresses and domain names. example: 192.168.0.10 and hydruspc.mydomain.local (ip.2 = 192.168.0.10, dns.2 = hydruspc.mydomain.local)

this would allow users to trust the root certificate at their own discretion on their devices and then avoid any and all certificate warnings when they connect to the hydrus api over https. certain modern server, http and browser requirements will halt communication if the certificate is untrusted (invalid). this simple process will trust the certificate and make it valid if the user so chooses. an example of a service that wont work without a trusted certificate is the user made https://hydrus.app/

for openssl the process is fairly simple and straight forward (i am unfamiliar with pythons' "cryptography" library and how to implement this process using it). here are the instructions and required configuration files (the configs can technically be included within the commands themselves, but i have not done this yet and therefore rely on the config files that are attached to the issue):

note: the configs have been renamed to "[...].txt" for github compatibility reasons; they dont allow .conf extensions.
you need to rename the text files to .conf for the commands below to work, or replace the .conf in the commands with .txt whichever you prefer

v3.txt
client.txt
hydrus-root.txt

root certificate (for users to import and trust)

1. generate a ca.key
   openssl genrsa -out hydrus-root.key 2048

2. generate your local hydrus-root.crt -- install and trust this certificate on your devices
   openssl req -x509 -new -nodes -key hydrus-root.key -sha256 -days 3650 -out hydrus-root.crt -config hydrus-root.conf

client.exe certificate

3. generate a new client.key -- put this file in the /db/ directory (replace old file if it exist)
   openssl genrsa -out client.key 2048

4. generate a client.csr to be signed using config)
   openssl req -new -sha256 -nodes -out client.csr -newkey rsa:2048 -keyout client.key -config client.conf

5. sign client.csr generating client.crt using config -- put this file in the /db/ directory (replace old file if it exist)
   openssl x509 -req -in client.csr -CA hydrus-root.crt -CAkey hydrus-root.key -CAcreateserial -out client.crt -days 365 -sha256 -extfile v3.conf

[imtbl]

Some more background information:

We've recently been getting more and more questions on the Discord server on how to access Hydrus media on mobile devices. https://hydrus.app/ is certainly the best option for this at the moment (featureful, good UI/UX), but generally requires the use of HTTPS with a valid certificate due browser restrictions. While the user could self-host hydrus-web (the application running on https://hydrus.app/) and use HTTP instead of HTTPS, more and more of hydrus-web's features (service workers etc.) rely on HTTPS, making this solution suboptimal.

But a "proper" HTTPS setup is quite involved; for the average person without developer/system administration background, learning how to set up a dynamic DNS (in case of a non-static IP), a reverse proxy server and generating a valid certificate (with Let's Encrypt, for example) is hard, especially since writing a generalized guide for it that requires no background knowledge is not really feasible. Such a setup is also often overkill or even undesirable (due to exposing the client API on WAN) if the user only wants to access the media within their LAN.

This proposal works around this issue by providing a simpler alternative directly through Hydrus; all that is required is pointing the user to an article on how to install the certificate on their device(s).