Nginx improvements. Closes #1499

[regulartim]

Description

This introduces several improvements to the nginx configuration:

1. The SSL config now lives in its own ssl.conf file which is not part of the repository. This means that on fresh installations or upgrades to the next version that includes this change, a single manual intervention is required. Instance admins need to copy and populate the prepared template file. Future changes to the https configuration file won't require any manual intervention.
2. No domain names are hardcoded in the config. The config doesn't even require domain names anymore.
3. The default nginx cipher list is used by default (can be changed in ssl.conf).
4. Duplication across different config files are down to a sensible minimum.
5. Location ^~/admin has been removed.
6. Caching or compression added to /static/ path.
7. Uniform upload size limits for dev and prod configuration.

Documentation for the Wiki

HTTPS

In production GreedyBear should be used with TLS enabled. To create self-signed certificates for testing or internal use, run this command with the appropriate information in -subj:

sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
  -keyout /etc/ssl/private/greedybear.key \
  -out /usr/local/share/ca-certificates/greedybear.crt \
  -subj "/C=DE/ST=Hessen/L=Frankfurt/O=YourOrg/CN=greedybear.yourorg.de"

Prepare your environment. Run the initialization with the --https flag:

# Production environment with HTTPS and external T-Pot Elasticsearch 
./gbctl init --https --elastic-endpoint http://tpot-host:64298

Now copy the TLS configuration template and change the paths, if necessary, such that they point to your SSL certificates. Your certificate and key must reside under /usr/local/share/ca-certificates/ and /etc/ssl/private/ respectively, as these are the only host directories mounted into the nginx container.

# Copy template and edit configuration
cp configuration/nginx/ssl.conf.template configuration/nginx/ssl.conf
nano configuration/nginx/ssl.conf

Note: The -nodes flag in the openssl command creates an unencrypted key, which nginx can read without further configuration. If you instead use an encrypted key, uncomment ssl_password_file in ssl.conf and point it at a file containing the passphrase. Nginx cannot prompt for one at startup and will fail to boot without it. That file must also live under /etc/ssl/private/.

Related issues

• Issues with nginx configuration files #1499

Type of change

• Bug fix (non-breaking change which fixes an issue).
• New feature (non-breaking change which adds functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as expected).
• Chore (refactoring, dependency updates, CI/CD changes, code cleanup, docs-only changes).

Checklist

Please complete this checklist carefully. It helps guide your contribution and lets maintainers verify that all requirements are met.

Formalities

• I have read and understood the rules about how to Contribute to this project.
• I chose an appropriate title for the pull request in the form: <feature name>. Closes #999
• My branch is based on develop.
• The pull request is for the branch develop.
• I have reviewed and verified any LLM-generated code included in this PR.

Docs and tests

• I documented my code changes with docstrings and/or comments.
• I have checked if my changes affect user-facing behavior that is described in the docs. If so, I also included an update to the wiki in the description of this PR.
• Linter (Ruff) gave 0 errors. If you have correctly installed pre-commit, it does these checks and adjustments on your behalf.
• I have added tests for the feature/bug I solved.
• All the tests gave 0 errors.

GUI changes

Ignore this section if you did not make any changes to the GUI.

• I have provided a screenshot of the result in the PR.
• I have created new frontend tests for the new component or updated existing ones.

Review process

• We encourage you to create a draft PR first, even when your changes are incomplete. This way you refine your code while we can track your progress and actively review and help.
• If you think your draft PR is ready to be reviewed by the maintainers, click the corresponding button. Your draft PR will become a real PR.
• If your changes decrease the overall tests coverage (you will know after the Codecov CI job is done), you should add the required tests to fix the problem.
• Every time you make changes to the PR and you think the work is done, you should explicitly ask for a review. After receiving a "change request", address the feedback and click "request re-review" next to the reviewer's profile picture at the top right.