Why the Nextcloud Client Does Not Accept Unsafe Connections

As of 3.17, the Desktop Client is enforcing HSTS headers.
### Symptom
The Desktop Client refuses connections to servers using unsafe certificates (e.g., self-signed ones).
### Background
When a server administrator enforces strict security, the client respects that choice. The end user cannot override this, because the server admin owns the data and is responsible for its integrity.
### Cause
If the web server sends an **HSTS (HTTP Strict Transport Security)** header, it instructs all clients to only connect via HTTPS **with a valid certificate chain**. Self-signed certificates do not meet this requirement.
🔗 [MDN docs: Strict-Transport-Security](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security)
### Why
This prevents insecure fallback. Without HSTS enforcement, attackers (e.g., on public Wi-Fi or behind a proxy) could intercept and decrypt traffic in a man-in-the-middle attack. By requiring valid certificates, the connection is guaranteed to be end-to-end encrypted and trusted.
### What You Can Do

- Install a valid TLS certificate (from Let’s Encrypt or another CA, including the full certificate chain), or
- Remove the HSTS header if you intentionally want to allow less strict connections (not recommended)
- if the HSTS header is removed, the client cache needs to be cleared
- check [here](https://doc.qt.io/qt-6/qstandardpaths.html) and search for `CacheLocation` for your OS

---
👉 In short: The Nextcloud client cannot be tricked into ignoring HSTS, because that would defeat the very protection HSTS is designed to provide.