Server: Enforce HTTPS via .htaccess edit

Created on 16 Jun 2016  路  52Comments  路  Source: nextcloud/server

Most helpful comment

I posted a bounty of 15$, will accept anything that allows me to force HTTPS via a GUI checkbox (not limited to .htaccess implementation).

All 52 comments

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

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

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

@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 https://github.com/owncloud/core/pull/14651

@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.

Awesome, its been removed

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

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.

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?

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

+1 :confused: .. 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

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!

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

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.

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~~~~

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

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

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.

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.

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...

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).

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.
                )

        )

)

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

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

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!

Me I had to add this in my .htaccess :

Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"

But there is an alternative, edit your apache conf : Enable HTTP Strict Transport Security

But there is an alternative, edit your apache conf : Enable HTTP Strict Transport Security

but some Admins want have dual solution and not only https ;)
best regards
Blacky

My Nextcloud is hosted by a webhoster, so i have no access to the apache conf...

And if I add this line
Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload"
to my .htaccess, I will probably get an manuplation error and the integrity check warning emerges again...

For those who have some problem, I share here what I did today with Nextcloud 11 and Nextcloud 10. Hope this will help someone.

WARNING

DO NOT REPLACE ALL YOUR FILES BY THE FOLLOWING SNIPPETS

Backup

first a backup of the current .htaccess and signature.json :

cp .htaccess .htaccess.bak
cp core/signature.json core/signature.json.bak

.htaccess

Old

<IfModule mod_rewrite.c>
  RewriteEngine on
  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]
</IfModule>

New

We are gonna add those 2 lines after RewriteEngine on

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

We finaly get :

<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]
</IfModule>

Get SHA512SUM of new version

sha512sum .htaccess

Result

a25b27be52575d88aa83d384de9e55076262041262fbe707b37e30f606d2291ffd094f0f70142aca5d77d3b1e23cdb8045fa1118d7913ac1b0e3bcbc8aac6f9d .htaccess

We only need the checksum which is in my case : a25b27be52575d88aa83d384de9e55076262041262fbe707b37e30f606d2291ffd094f0f70142aca5d77d3b1e23cdb8045fa1118d7913ac1b0e3bcbc8aac6f9d so we're gonna copy it to the file core/signature.json

core/signature.json

Old

{
    "hashes": {
        ".htaccess": "ab5f4c44ba2f9c66f2ed25c3ad3d84660b2808cca11ffa8fe2778a648a054d8ada495a0bf4715dc873aac1efe8dfd92a72f9a24441d8f5240834e639325fd892"
    },
    "signature": "avHuGdaBjxGen+cMeURgVAPlzvD\/Y495QnzLFG0RLgYKoAR27Uh5iUtPYYQKzbTpGv84dIyq7AyXAoSvowTQs5PAYx1xyBxotl6AN3HM4l32pvxC5H3UdeWtoXybObAy4h7SV0h5HHQm8Re8stKktm5gUCRuD5S0TJ7ESMaUTmnRxnGD4oBS6TUnPSACTINCsaKmcSBG3iV4DiZYdHsnSoVJwZss8MqLHC5\/eCkF8ruUQZFyXiW1931nIbFP9j4JeRfAM1fp58ZDH\/SIP3wn9Axd9Gcz+lf67LB7sr7loaNc77nmEHjQdQ35xkEqrGst2xvgneNg8ncPE863NbqPcg==",
    "certificate": "-----BEGIN CERTIFICATE-----\r\nMIIEojCCA4qgAwIBAgICEAAwDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCREUx\r\nGzAZBgNVBAgMEkJhZGVuLVd1ZXJ0dGVtYmVyZzEXMBUGA1UECgwOTmV4dGNsb3Vk\r\nIEdtYkgxNjA0BgNVBAMMLU5leHRjbG91ZCBDb2RlIFNpZ25pbmcgSW50ZXJtZWRp\r\nYXRlIEF1dGhvcml0eTAeFw0xNjA2MTIyMTA1MDZaFw00MTA2MDYyMTA1MDZaMGYx\r\nCzAJBgNVBAYTAkRFMRswGQYDVQQIDBJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNV\r\nBAcMCVN0dXR0Z2FydDEXMBUGA1UECgwOTmV4dGNsb3VkIEdtYkgxDTALBgNVBAMM\r\nBGNvcmUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUxcrn2DC892IX\r\n8+dJjZVh9YeHF65n2ha886oeAizOuHBdWBfzqt+GoUYTOjqZF93HZMcwy0P+xyCf\r\nQqak5Ke9dybN06RXUuGP45k9UYBp03qzlUzCDalrkj+Jd30LqcSC1sjRTsfuhc+u\r\nvH1IBuBnf7SMUJUcoEffbmmpAPlEcLHxlUGlGnz0q1e8UFzjbEFj3JucMO4ys35F\r\nqZS4dhvCngQhRW3DaMlQLXEUL9k3kFV+BzlkPzVZEtSmk4HJujFCnZj1vMcjQBg\/\r\nBqq1HCmUB6tulnGcxUzt\/Z\/oSIgnuGyENeke077W3EyryINL7EIyD4Xp7sxLizTM\r\nFCFCjjH1AgMBAAGjggFDMIIBPzAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIG\r\nQDAzBglghkgBhvhCAQ0EJhYkT3BlblNTTCBHZW5lcmF0ZWQgU2VydmVyIENlcnRp\r\nZmljYXRlMB0GA1UdDgQWBBQwc1H9AL8pRlW2e5SLCfPPqtqc0DCBpQYDVR0jBIGd\r\nMIGagBRt6m6qqTcsPIktFz79Ru7DnnjtdKF+pHwwejELMAkGA1UEBhMCREUxGzAZ\r\nBgNVBAgMEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAGA1UEBwwJU3R1dHRnYXJ0MRcw\r\nFQYDVQQKDA5OZXh0Y2xvdWQgR21iSDEhMB8GA1UEAwwYTmV4dGNsb3VkIFJvb3Qg\r\nQXV0aG9yaXR5ggIQADAOBgNVHQ8BAf8EBAMCBaAwEwYDVR0lBAwwCgYIKwYBBQUH\r\nAwEwDQYJKoZIhvcNAQELBQADggEBADZ6+HV\/+0NEH3nahTBFxO6nKyR\/VWigACH0\r\nnaV0ecTcoQwDjKDNNFr+4S1WlHdwITlnNabC7v9rZ\/6QvbkrOTuO9fOR6azp1EwW\r\n2pixWqj0Sb9\/dSIVRpSq+jpBE6JAiX44dSR7zoBxRB8DgVO2Afy0s80xEpr5JAzb\r\nNYuPS7M5UHdAv2dr16fDcDIvn+vk92KpNh1NTeZFjBbRVQ9DXrgkRGW34TK8uSLI\r\nYG6jnfJ6eJgTaO431ywWPXNg1mUMaT\/+QBOgB299QVCKQU+lcZWptQt+RdsJUm46\r\nNY\/nARy4Oi4uOe88SuWITj9KhrFmEvrUlgM8FvoXA1ldrR7KiEg=\r\n-----END CERTIFICATE-----"
}

New

So here we replace the old checksum of .htaccess ONLY with the copied one

We finaly get (in my case) :

{
    "hashes": {
        ".htaccess": "a25b27be52575d88aa83d384de9e55076262041262fbe707b37e30f606d2291ffd094f0f70142aca5d77d3b1e23cdb8045fa1118d7913ac1b0e3bcbc8aac6f9d"
    },
    "signature": "avHuGdaBjxGen+cMeURgVAPlzvD\/Y495QnzLFG0RLgYKoAR27Uh5iUtPYYQKzbTpGv84dIyq7AyXAoSvowTQs5PAYx1xyBxotl6AN3HM4l32pvxC5H3UdeWtoXybObAy4h7SV0h5HHQm8Re8stKktm5gUCRuD5S0TJ7ESMaUTmnRxnGD4oBS6TUnPSACTINCsaKmcSBG3iV4DiZYdHsnSoVJwZss8MqLHC5\/eCkF8ruUQZFyXiW1931nIbFP9j4JeRfAM1fp58ZDH\/SIP3wn9Axd9Gcz+lf67LB7sr7loaNc77nmEHjQdQ35xkEqrGst2xvgneNg8ncPE863NbqPcg==",
    "certificate": "-----BEGIN CERTIFICATE-----\r\nMIIEojCCA4qgAwIBAgICEAAwDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCREUx\r\nGzAZBgNVBAgMEkJhZGVuLVd1ZXJ0dGVtYmVyZzEXMBUGA1UECgwOTmV4dGNsb3Vk\r\nIEdtYkgxNjA0BgNVBAMMLU5leHRjbG91ZCBDb2RlIFNpZ25pbmcgSW50ZXJtZWRp\r\nYXRlIEF1dGhvcml0eTAeFw0xNjA2MTIyMTA1MDZaFw00MTA2MDYyMTA1MDZaMGYx\r\nCzAJBgNVBAYTAkRFMRswGQYDVQQIDBJCYWRlbi1XdWVydHRlbWJlcmcxEjAQBgNV\r\nBAcMCVN0dXR0Z2FydDEXMBUGA1UECgwOTmV4dGNsb3VkIEdtYkgxDTALBgNVBAMM\r\nBGNvcmUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUxcrn2DC892IX\r\n8+dJjZVh9YeHF65n2ha886oeAizOuHBdWBfzqt+GoUYTOjqZF93HZMcwy0P+xyCf\r\nQqak5Ke9dybN06RXUuGP45k9UYBp03qzlUzCDalrkj+Jd30LqcSC1sjRTsfuhc+u\r\nvH1IBuBnf7SMUJUcoEffbmmpAPlEcLHxlUGlGnz0q1e8UFzjbEFj3JucMO4ys35F\r\nqZS4dhvCngQhRW3DaMlQLXEUL9k3kFV+BzlkPzVZEtSmk4HJujFCnZj1vMcjQBg\/\r\nBqq1HCmUB6tulnGcxUzt\/Z\/oSIgnuGyENeke077W3EyryINL7EIyD4Xp7sxLizTM\r\nFCFCjjH1AgMBAAGjggFDMIIBPzAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIG\r\nQDAzBglghkgBhvhCAQ0EJhYkT3BlblNTTCBHZW5lcmF0ZWQgU2VydmVyIENlcnRp\r\nZmljYXRlMB0GA1UdDgQWBBQwc1H9AL8pRlW2e5SLCfPPqtqc0DCBpQYDVR0jBIGd\r\nMIGagBRt6m6qqTcsPIktFz79Ru7DnnjtdKF+pHwwejELMAkGA1UEBhMCREUxGzAZ\r\nBgNVBAgMEkJhZGVuLVd1ZXJ0dGVtYmVyZzESMBAGA1UEBwwJU3R1dHRnYXJ0MRcw\r\nFQYDVQQKDA5OZXh0Y2xvdWQgR21iSDEhMB8GA1UEAwwYTmV4dGNsb3VkIFJvb3Qg\r\nQXV0aG9yaXR5ggIQADAOBgNVHQ8BAf8EBAMCBaAwEwYDVR0lBAwwCgYIKwYBBQUH\r\nAwEwDQYJKoZIhvcNAQELBQADggEBADZ6+HV\/+0NEH3nahTBFxO6nKyR\/VWigACH0\r\nnaV0ecTcoQwDjKDNNFr+4S1WlHdwITlnNabC7v9rZ\/6QvbkrOTuO9fOR6azp1EwW\r\n2pixWqj0Sb9\/dSIVRpSq+jpBE6JAiX44dSR7zoBxRB8DgVO2Afy0s80xEpr5JAzb\r\nNYuPS7M5UHdAv2dr16fDcDIvn+vk92KpNh1NTeZFjBbRVQ9DXrgkRGW34TK8uSLI\r\nYG6jnfJ6eJgTaO431ywWPXNg1mUMaT\/+QBOgB299QVCKQU+lcZWptQt+RdsJUm46\r\nNY\/nARy4Oi4uOe88SuWITj9KhrFmEvrUlgM8FvoXA1ldrR7KiEg=\r\n-----END CERTIFICATE-----"
}

Final Tasks

Test

Open you browser and access to your cloud domains without https extensions and normaly it'll redirect you to https.

Delete Backups

rm .htaccess.bak
rm core/signature.json.bak

ow wow, a "Profi" *bg*
it solve if it make in the **cloud as automatic file
change by checkbox in the administration, it don't need a
specially "you have do it like i told" there, because the most peoples who
be in github, have a know how it works, but thank you for you contribution and support..
(wth. i had only see in my mail a "WARNING" fu.... *loooll*)

best regards
Blacky

@blackcrack At least there are people on github who, unlike you, try to help and contribute.

You, apparently, can do nothing but complain and demand work and time from others. Your whole post history is a stream of complaints and demands. If you think this is an important issue, go and fix it and contribute your code. If you can only complain and insult people who try their best with workarounds, then please leave. "fu loooooooooooll."

humm.. this is a issue tread and not a wiki tread.
and by the way, why do he it not solve..
or you ?
thank you.

Because you first don't respect 2 or more aspect of the Code of Conduct of this community, you don't deserve an answer or even a comment about your responses @blackcrack.

oh, why do you answer ?
this tread should be closed !
thank you ..

@funilrys your solution seems to work fine for me, thank you! Maybe we should add a checkbox which adds those two lines to the htaccess file. So we could keep the setting after updates of nextcloud.

But I'm not good enough in PHP to do this... Anyway thank you!

This is a really annoying issue, particularly because my htaccess edits get reverted after every upgrade. Weirdly I never had to deal with integrity errors and never had to edit any other files.

I don't really understand why the config.php option was removed, enforcing this via PHP seems like a better (and more portable) solution than relying on the user to set this up correctly.

I posted a bounty of 15$, will accept anything that allows me to force HTTPS via a GUI checkbox (not limited to .htaccess implementation).

Hi.
Are there any news on #132 ?

No, please add to bounty.

For everyone who is facing that problem and is looking for an easy to handle solution.
This solution works for all webhosted products. I麓ve successfully applied it at 5 installations

How to embed? I have uploaded this screenshot for you.

@wmcgit same thing as I said there

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?

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

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

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.

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.

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

not everyone has the ability to change their vhost config.

Then alternative in .htaccess:

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

@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.

Then alternative in .htaccess:

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

It worked great for me. Thanks !

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.

Was this page helpful?
0 / 5 - 0 ratings