Enforce HTTPS via .htaccess edit

[LukasReschke]

Also offer GUI checkbox, check https://help.nextcloud.com/t/enforce-https-via-htaccess-file-integrity-check-error/663/4

[williambargent]

@LukasReschke You can already force HTTPs in the config/config.php file.

'forcessl' => true,
'forceSSLforSubdomains' => true,

[ambux]

The forcessl-lines in config.php do not have an effect in my installation.

[MorrisJobke]

@LukasReschke You can already force HTTPs in the config/config.php file.

They aren't present anymore since some versions - it was removed in 8.1 owncloud/core#14651

[williambargent]

@MorrisJobke Oh, well it's still in the documentation.
https://docs.nextcloud.org/server/9/admin_manual/configuration_server/config_sample_php_parameters.html?highlight=config

[MorrisJobke]

@MorrisJobke Oh, well it's still in the documentation.

I can't find it on that page anymore 🙈 Could you check again? I searched for forcessl.

[williambargent]

Awesome, its been removed

[blackcrack]

enabling https redirecting directly in .htaccess via checkbox in Adminarea would be really nice :)

https://forum.owncloud.org/viewtopic.php?f=21&t=34397&p=110792#p110792

<IfModule mod_rewrite.c>
RewriteEngine on
#-
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
#-
RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
RewriteRule ^\.well-known/host-meta\.json /public.php?service=host-meta-json [QSA,L]
RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
RewriteRule ^remote/(.*) remote.php [QSA,L]
RewriteRule ^(build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
RewriteRule ^(\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]

and so on ..

maybe setting up via checkbox in the Adminarea if this works :

RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

and resetting up the HASH'es and correcting them ..

best regards
Blacky

[Spacefish]

i have simply done this in my webserver configuration (nginx). If we introduce a GUI checkbox in admin panel, we should make sure, that the user is able to access the installation via https (iframe with a token?!). Otherwise you may get locked out of your installation, once you enable that checkbox.

[sushidave]

This integrity check error also happens when you need to enable/modify the HTTP Strict Transport Security header in htaccess, see https://docs.nextcloud.com/server/9/admin_manual/configuration_server/harden_server.html#enable-http-strict-transport-security. How about adding this option to the GUI in the same run?

[MariusBluem]

Why was the checkbox removed with 8.1 😕 ..I think it caused bugs? @LukasReschke

[blackcrack]

+1 😕 .. a more easy possible would it be, change the .htaccess'es and make 2 of them, by check a checkbox change they are and change the hashes also.. as a suggestion for have the possible also use every a ssl protocol by any addresses and move it to https in any case, by checking the Checkbox '[X] Every using a Https Protocol '.

best regards
Blacky

[Lancer107]

Hi there,
I was on Nextcloud 9.53 and made a manual update on my shared Hoster to Nextcloud 10.
Everything works fine, but i got also the integrity check error if i modify my .htaccess in the main directory /nextcloud.
I've tried to copy my .htaccess from my old Nextcloud and also modify the new .htaccess from Nextcloud 10.
Both attemps ends in the integrity check error for the .htaccess file.
In Nextcloud 9.53 it was no problem to edit this file. The integrity check had nothing to complain about.

So, does Nextcloud 10 now check also the .htaccess files and how can I successfully implement my code?
I've added this lines:

RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule (.*) https://my-domain.com/nextcloud/$1 [R=301,L]
Header set Strict-Transport-Security "max-age=31536000" env=HTTPS

Someone got an idea?

Thanks in advance!

[ggeorgg]

I do have the same problem with the .htaccess file. I would really like to have this checkbox in the admin area 👍

[Lancer107]

In NextCloud 9.53 i have made the same adjustments in the .htaccess and the integrity check was OK.
May it's a bug in Version 10?
The best way i can imagine would be an option to exclude some files like the .htaccess.

[blackcrack]

humm.. :

-----snipp-----Version 9-----------------------
<IfModule mod_rewrite.c>
  RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
  RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
  RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
  RewriteRule ^\.well-known/host-meta\.json /public.php?service=host-meta-json [QSA,L]
  RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
  RewriteRule ^remote/(.*) remote.php [QSA,L]
  RewriteRule ^(build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
  RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
  RewriteRule ^(\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]

  # Rewrite rules for `front_controller_active`
  Options -MultiViews
~~~blablabla~~~~

[Martin-By]

Oh what a pit, I am hosting on HostEurope and also use a rewrite rule in .htaccess for HTTPS support.

The integrity hint gives me the actual hash of my changed .htaccess file. Any way to correct the expected hash value manually?

Best Regards,

Martin

[blackcrack]

nope, i have the same problem and looking over away for have a https automatical ..
i have try to change the hash-file but it have works not.. unfortunately so i change only the .htaccess file and accept the message about the wrong hash .. :\ but i use at moment the vers. 9 because the automagically update procedure do curiously not work..
best regards
Blacky

[JaimeObregon]

A quick summary as of today and under a freshly installed Nextcloud 10.0:

• HTTPS not enforced by default.
• 'forcessl' => true in config/config.php has no effect.
• Out-of-the-box .htaccess does not contain any rules enforcing secure connections either.
• The security check at /settings/admin detects and warns about this security risk, providing a link to docs on "security tips".
• The link (to #admin-tips) is broken (at least under my fresh installation in Spanish).

As the default installation is currently unsecure by default, I'd suggest reconsidering the priority assigned to this issue.

[zpuskas]

Manual workaround is that after adding the two extra lines for enforcing https (see @blackcrack comment above) just do this:
$ sha512sum .htaccess
$ vim core/signature.json
... replace the hash for .htaccess, save and exit
And viola, enforced https and no signature complaints from the system.

[Lancer107]

Well, that will not realy work...
I have already tested this solution, but if i "manipulate" the signatures, the following Error appears:

`Technical information

The following list covers which files have failed the integrity check. Please read
the previous linked documentation to learn more about the errors and how to fix
them.

Results

• core
  • EXCEPTION
    • OC\IntegrityCheck\Exceptions\InvalidSignatureException
    • Signature could not get verified.`

So, this is not a fine solution for out Problem...

[zpuskas]

I did this on Nextcloud stable version 10.0.1 and actually did the editing locally. So I have downloaded .htaccess and core/signature.json and then uploaded them back after editing.

Your output does not specify the file that failed the hash check, but instead says that the signature is invalid. So very likely your hash is not a valid sha512 hash (typo during editing?). Maybe check if your editor changes end of line or if that you copied only the hash output from sha512sum?

Example:
$ sha512sum .dummy-htaccess 0e3e75234abc68f4378a86b3f4b32a198ba301845b0cd6e50106e874345700cc6663a86c1ea125dc5e92be17c98f9a0f85ca9d5f595db2012f7cc3571945c123 .dummy-htaccess

Then you only need the
0e3e75234abc68f4378a86b3f4b32a198ba301845b0cd6e50106e874345700cc6663a86c1ea125dc5e92be17c98f9a0f85ca9d5f595db2012f7cc3571945c123
part, no spaces or new lines or anything. Make sure you did not break the json formatting either (e.g. missing double quotes) or that you did not miss any characters from the hash.

I have no errors either on the UI or when running signature check manually on the terminal (./occ integrity:check-core).

[Lancer107]

Yes, thats what i did.
I've copied the .htaccess to my Linux-PC and creat the hash with "$ sha512sum .htaccess"
Than copied the Signature.json to my PC, changed the Hashes an save. Reupload it to my WebSpace.
The old integrity check is still warning my, the full Error see below:
(yes, i have made a rescan of the Files)

Error-Message:

Technical information
=====================
The following list covers which files have failed the integrity check. Please read
the previous linked documentation to learn more about the errors and how to fix
them.

Results
=======
- core
    - EXCEPTION
        - OC\IntegrityCheck\Exceptions\InvalidSignatureException
        - Signature could not get verified.

Raw output
==========
Array
(
    [core] => Array
        (
            [EXCEPTION] => Array
                (
                    [class] => OC\IntegrityCheck\Exceptions\InvalidSignatureException
                    [message] => Signature could not get verified.
                )

        )

)

[blackcrack]

this .htaccess file should be twice exist one with https and one without redirect.
and a option in the admin-area via checkbox where change the both
and reconfiguring the hash of the file (and the signature) in the nextcloud.
to have the possible for have a https redirection in the cloud.

please, can this do anybody who can php/Java,
i have to less time with my 12h refugee safety job.

best regards
blacky

[boTux]

You can add 'overwriteprotocol' => 'https', in your config/config.php
Tested on version 10.0.1 & don’t forget to check the sample config :p

[Lancer107]

Yeah, that works!
But now i have another "Problem"...
I have also add the following code in my .htaccess:

Header set Strict-Transport-Security "max-age=31536000" env=HTTPS

Now, with the original .htaccess and the 'overwriteprotocol' => 'https', line in the config.php,
i don't know where i can set this...
Without setting this, i also got an red warning in the Administrator settings that the Strict-Transport-Security" HTTP-Header is not set to minimal "15552000" Sec. It is reommended to activate hsts.

Do anyone know a solution?

And thanks a lot to boTux for the overwriteprotocol Solution!

[MichaIng]

Any progress here? As occ maintenance:update:htaccess in case also changes .htaccess without producing an integrity check error, it will also adjust the checksum. So that way the checkbox(es) could also work. I personally would merge HTTPS with HSTS so be enabled together.
Maybe it is possible to send the request of the checkbox/related settings page directly via https, so that trying to enable/access it simply does not work, if https does not reach the server?

[blackcrack]

Hi,

'forcessl' => true,
'forceSSLforSubdomains' => true,

like further on top described ^^

in config.php it is a good choice it is enabled again in vers 13. of Nextcloud
via checkbox in the config , this makes to be ever redirected to https,
if this option setting up again in include in the code again, have we no
task in this https direction anymore :) because, it works simply again
without an changing of the .htaccess and we have no trouble any more :)

best regards
Blacky

[domhardt]

Hi,

I switched from owncloud 8.x to a fresh install of nextcloud 12.0.3 on my webspace (Hetzner Level 4). While "installation" (unzipping) and https is working fine I can't get rid of the HSTS warning on the nextcloud admin page. Over the last four hours I have tried EVERY single tipp but with no success.

I would like to see a default setup with correct HTTPS and HSTS settings when the install routine was started from a https-link. Maybe these setting can be in the config.php because the .htaccess entries show no effect in my case (again: Hetzner Level 4).

best regards
Michael

[MichaIng]

If the .htaccess does have any effect, quickly contact your hosting provider to enable AllowOverride All for your nextcloud folder. Your data could be unprotected otherwise. After that the HSTS header inside .htaccess should have the desired effect.

[My1]

I really hope this setting comes back again, in best case with a setting for plain redirect and HSTS each. while HSTS isnt a bad thing in general it's kinda annoying when you screw up soemthing with your certs, and the browsers dont give you a "thanks I know, I trust this cert anyway" option.

while HSTS is truly a godsend for things that are open to the public, a closed party like my cloud where only I have access anyway I prefer to say how I like my stuff, in this case with a plain redirect (like back in OC6) and no HSTS.

but for now the overwriteprotocol setting is pretty awesome. thanks.

[kakhavk]

Add this Redirect with your url on nextclouds virtualhost:
Redirect permanent / https://youurl

[My1]

not everyone has the ability to change their vhost config.

[kakhavk]

Then alternative in .htaccess:

RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

[MichaIng]

@kakhavk
Isn't it possible to add the Redirect directive to .htaccess as well? It looks looks like the cleaner solution to me, compared to Rewrite, to let the browser send a new request on HTTPS and remember this via HSTS.

Further reading: https://httpd.apache.org/docs/2.4/rewrite/avoid.html

• Okay, so redirect should be preferred, if possible
• But within .htaccess it seems not to be possible, so rewrite needs to be done.

[rzbuno]

Then alternative in .htaccess:

RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

It worked great for me. Thanks !

[MichaIng]

One could add some flags, e.g.: https://httpd.apache.org/docs/2.4/mod/mod_rewrite.html#rewriterule

RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [END,NE,R=permanent]

END: Do not apply any further rewrite rules
NE: Do not escape special characters (via hex codes) but rewrite the URI as is
R=permanent: Do a permanent redirect, hence the browser sends a new request with https

AFAIK NE might be required to not break access tokens in query strings.
Not sure if R has any effect here since the protocol shift (http => https) requires a new request anyway? Usually a rewrite does not change the URL in browser, compared to a redirect, so is only done internally, however in case of https rewrite the browser URL changes in every case.

[JialuZhang]

@tom967 @kakhavk

Having just

RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

is a silent misconfiguration. Since "RewriteEngine" is by default set to off, it is a must to add "RewriteEngine on" in configuration file, if we want to enable the functionality of "RewriteCond" and "RewriteRule".

Here is the related Apache source code snippet:

run_rewritemap_programs(server_rec *s , apr_pool_t *p){
if (conf->state == ENGINE_DISABLED) { // usage of "RewriteEngine"
  return APR_SUCCESS; // early return
rewritemap_program(...); // usage of "RewriteRule" 
}

[rzbuno]

Thanks !

[MichaIng]

Good hint, however, it is enabled anyway by the current .htaccess, as long as the module is 😉: https://github.com/nextcloud/server/blob/master/.htaccess#L59-L70

[sparusaurata]

As suggested several times

RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

should work but on my web host I had to add

RewriteCond %{HTTP:X-Forwarded-Proto} !https

between the two lines, for some reason (otherwise I get an error "bad redirection" in my browser). I just put it here in case it could help someone.

[MichaIng]

I guess in cases where the client connection was HTTPS already but a proxy terminates that connection and uses plain HTTP to connect to the final webserver.

[kesselb]

As this sounds like a nice feature, the requests for this are quite low. Currently there are no plans to implement such a feature. Thus I will close this ticket for now. This does not mean we don't want this feature, but it is simply not on our roadmap for the near future. If somebody wants to implement this feature nevertheless we are happy to assist and help out.