HSTS is not configurable in the GUI

[hubertmeier]

i built a nextcloupi and use only a portforwading 443 -> 8445 in the router, i do not use letsencrypt or so. The domain

xxxxx.myfritz.net

is added to the trusted-domains. Its not really clear, if there must be an entry like xxxxx.myfritz.net:8445 or without the port. Further the hostname nc5 is added too ...

Obviously is HSTS activated, the client 3.17. does not accept the certificate, the browsers work all without problems. There is absolutely no hint in the GUI that HSTS exists and the status, activated or not or the possibility to change that.

So i can use only Client 3.16. or earlier to access the nextcloud. The same problem appeared with an older nextcloudpi which worked for years after the clinet update to 3.17.

I think, many many nextcloud instances run like this.

I asked this problem in the nextcloudclient section, but the question, is HSTS is for me difficult to answer. Theoretically should a standard installations work directly ...

It would be nice, to have a solution in the GUI which can proove and configure these settings.

I find lot of instructions how to activate HSTS but no instructions how to disable (or proove the status) of HSTS

[theCalcaholic]

Hi, thanks for reporting. Just to understand you correctly: What exactly is running on port 8445?

[hubertmeier]

Port 8445 is the extern forwarded port 443 from the Nextcloudpi

Xxxxx.myfritz.net:8445 -> 192.x.x.x:443

For an older Nextcloudpi I use extern 8444

[hubertmeier]

Hi again, disabling HSTS by commenting out the header in the file /etc/apache2/sites-available/001-nextcloud.conf is obviously not enough to get the desktop client 3.17. to work. The header is really not sent now, but the client does not accept a self signed certificate.

The changes made in client 3.17. are not really clear, they stated that HSTS is the problem (its not a bug, its a security feature), but with deactivated HSTS-Header the problem remains. The acces per browser works (unsecure, with accepting the self signed certificate). So we need a nextcloupi-configuration which works with self-signed certificates and forwarded ports. Is it possible that the portforwarding (intern 443, extern 8445) causes these problems?

[theCalcaholic]

Hi again, disabling HSTS by commenting out the header in the file /etc/apache2/sites-available/001-nextcloud.conf is obviously not enough to get the desktop client 3.17. to work. The header is really not sent now, but the client does not accept a self signed certificate.

The changes made in client 3.17. are not really clear, they stated that HSTS is the problem (its not a bug, its a security feature), but with deactivated HSTS-Header the problem remains. The acces per browser works (unsecure, with accepting the self signed certificate). So we need a nextcloupi-configuration which works with self-signed certificates and forwarded ports. Is it possible that the portforwarding (intern 443, extern 8445) causes these problems?

The idea of hsts is, that a client which at some point received a valid certificate will refuse to accept connections with an invalid or no certificate in the future. So for a client that has already connected to your NCP instance, it won't make a difference whether you disable HSTS afterwards.

I have to look into it more thoroughly, but ideally, NCP would offer two solutions here, if you're using self signed certificates:

1. Download the certificate from the admin interface to add it to your operating system's and browser's trust stores
2. Disable HSTS

You could already do the first, btw, by downloading the offending certificate from your browser when visiting any page that uses it (usually clicking on the lock icon in the address bar will get you there).

[da666er]

For me it worked that way:

Disable hsts in apache conf file /etc/apache2/sites-enabled/001-nextcloud.conf:
Comment out Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains"

Restart apache daemon:
systemctl restart apache2

Update windows nextcloud desktop client to version 3.17.3

Stop the desktop client

Delete hsts cache file C:\Users\username\AppData\Local\Nextcloud\cache\hstsstore
On linux I think this file is located here: ~/.cache/Nextcloud/hstsstore

Connect and sync after that worked again!

[Jaxan]

I did the same on my windows client and that works great. (Commenting out the line in the apache config, and removing the cache and restarting.)

But for MacOS, it doesn't work :-(. I'm still figuring out why. The client shows the changed files in the "activity pop-up", but it doesn't actually sync files. And in the logs, there are warnings about certificates...

Edit: I have a suspicion that it may have to do with the notiy_push app, their README also mentions somethings about HSTS. Because if I do "remove download" and double-click a file, it will give me the newest version. So syncing works somewhat.

[tschenkelz]

Hello.

I use nextcloud AIO and I dont see a reasonable way to deal with this issue.
I cannot connect to my nextcloud with my nextcloud desktop app anymore.

I use my own CA at my nextcloud. Worked before, now I cant get it back to work.