Koozali.org: home of the SME Server
Obsolete Releases => SME 9.x Contribs => Topic started by: edb on June 26, 2018, 05:13:41 PM
-
Ever since I have installed the Nextcloud contrib I have run into a weird issue which I will try to explain.
The Nextcloud contrib works fine and is accessed via https://www.mydomain.com/nextcloud and all works well.
The issue that I am experiencing is that I have another site at just http://www.mydomain.com:8440 for another app I'm using and the issue comes into play as follows:
When I navigate to https://www.mydomain.com/nextcloud (even just having the page up) and then try to go to http://www.mydomain.com:8440 after I am presented with the following error in my browser (Chrome or Firefox) Error code: SSL_ERROR_RX_RECORD_TOO_LONG and I can no longer access my site at http://www.mydomain.com:8440 because it tries to automatically change the http to https which will not work.
After some searching it appears that everything regarding the two sites works fine in Microsoft Edge or Internet Explorer browsers but just won't work in any other browsers.
To temporarily resolve the issue I did the following in Chrome ... Go to chrome:net-internals/#hsts go to the bottom of that page and in Delete Domain security policy type in "www.mydomain.com" then click Delete.
Once this has been done I can immediately directly access my site at http://www.mydomain.com:8440 again and all is fine and wonderful.
As soon as I would navigate to the nextcloud site at https://www.mydomain.com/netcloud the whole issue would start all over again until I would perform the temporary resolve routine again.
There must be something in the Nextcloud contrib that is causing this annoying problem but I can't figure out what.
The nextcloud site must be sending or caching something to cause this problem.
Any help appreciated otherwise I guess Nextcloud will have to go because I need the other apps more.
-edb
-
There must be something in the Nextcloud contrib that is causing this annoying problem but I can't figure out what.
Yes, Nextcloud (or, more precisely, the smeserver-nextcloud contrib) is implementing HSTS. The best answer is to put a certificate on your other machine so it can talk https too. Failing that, someone else will have to chime in with the best way to disable HSTS in the controb.
-
Thanks for your reply and confirmation regarding the HSTS implementation which certainly would explain my issue.
The choices that you mention are likely all that I have and I would need to figure out how to get the other site setup with https (it's Screen Connect) that I'm using for that other site using just http right now. It seems like a big task to get it working with https and my current certificate but I may just have to do it regardless.
I just know that it all worked fine until I installed the smeserver-nextcloud contrib and otherwise I think the contrib is pretty darn good.
Here is what I found with a Google ... this would explain why when I type HTTP and it goes to HTTPS
How to Enable HTTP Strict Transport Security (HSTS)
HTTP Strict Transport Security (HSTS) is a security mechanism in which a website tells the browser that all future requests should be made over HTTPS. Using HSTS will force all future requests to the current domain name to use https:// URLs even if the user attempts to go to links using http:// URLs.
You can enable HSTS headers by adding the following in a .htaccess file in your app's web root directory (public):
# Using this header, any browser that accesses the site over HTTPS will not
# be able to access the plain HTTP site for one year (31536000 seconds).
# One you begin using this, you should not stop using SSL on your site or
# else your returning visitors will not be able to access your site at all.
Header always set Strict-Transport-Security "max-age=31536000" env=HTTPS
Once you enable HSTS, you are committed to SSL. You will not be able to go back to plain HTTP for your app.
If you want to force users to HTTPS, you will still need to redirect from HTTP to HTTPS.
I think this site explains HSTS well and why it is necessary to stop man-in-the-middle attacks.
https://www.owasp.org/index.php/HTTP_Strict_Transport_Security_Cheat_Sheet
This is all stuff I didn't know until just now so kind of a blessing in a way.
I think my best approach is to make all my sites https to be the safest.
-
Instead of portforwarding use a reverse proxy command in appache. Search the wiki for way to implement it. This will make your application encrypted over the internet, which is important, without handling the ssl on this secondary server but only on your sme server.
-
I have not installed Nextcloud on my SME server, but...
You would eliminate the HSTS problem if your Nextcloud instance used a different hostname - "https://nextcloud.mydomain.com" instead of "https://www.mydomain.com".
It looks like the configuration (https://wiki.contribs.org/Nextcloud#Configuration) pieces are in place in the contrib, using something like this:
config setprop nextcloud VirtualHost nextcloud.mydomain.com
signal-event nextcloud-update
(I don't know if you need to then create the new domain in server-manager or not)
Alternatively, leave nextcloud on www.mydomain.com and set a different hostname for the other service.
-
Hi edb,
I am not using Nextcloud but I had a similar problem with an Odoo site using port 8069 and https: "SSL_ERROR_RX_RECORD_TOO_LONG"
- original site: toto.org
- Odoo: toto.org:8069
As suggested by reetP:
- For the https problem, in Server Manager, add another domain to your SME Server: odoo.toto.org
# mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts
# cp /etc/e-smith/templates/etc/httpd/conf/httpd.conf/VirtualHosts/25SSLDirectives /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts
# cat > /etc/e-smith/templates-custom/etc/httpd/conf/httpd.conf/VirtualHosts/25SSLDirectives <<'EOT'
{
if ( $port eq "80" && $virtualHost eq "odoo.toto.org")
{
$OUT .= " \n";
$OUT .= " # For the redirection of Odoo.\n";
$OUT .= " Redirect / https://odoo.toto.org/\n";
}
return " # skipping SSL directives\n" unless $port eq "443";
return "" unless $modSSL{'status'} eq 'enabled';
$OUT = <<SSL_END;
# SSL Directives
SSLEngine on
SSL_END
if ( $virtualHost eq "odoo.toto.org" )
{
$OUT .= " \n";
$OUT .= " # For the redirection of port 8069\n";
$OUT .= " ProxyPass / http://localhost:8069/ retry=0\n";
$OUT .= " ProxyPassReverse / http://localhost:8069/\n";
}
}
EOT
# expand-template /etc/httpd/conf/httpd.conf
# /etc/rc.d/init.d/httpd-e-smith restart
# /etc/rc.d/init.d/odoo restart
- I added CNAMEs at my registrar in my domain toto.org: odoo, www.odoo, ftp.odoo, mail.odoo, proxy.odoo and wpad.odoo all pointing to @.
- I added to my Let's Encrypt /etc/dehydrated/domains.txt: odoo.toto.org www.odoo.toto.org ftp.odoo.toto.org mail.odoo.toto.org proxy.odoo.toto.org wpad.odoo.toto.org
- I forced Let's Encrypt to renew the certificate to add the new domain and hosts.
- I must not use http://www.toto.org:8069 anymore but to access my odoo site from now on, I must use: https://www.odoo.toto.org.
- If I use https://www.toto.org:8069, I will still get ther error: "SSL_ERROR_RX_RECORD_TOO_LONG".
I don't know if this will resolve your problem with Nextcloud but for me, it resolved my problems of https and "SSL_ERROR_RX_RECORD_TOO_LONG". This example might points out something...
Michel-André
-
Thank you all for your replies. All good suggestions so thanks!
-
I was eventually able to get my other web app set up to use HTTPS on a different port since 443 was already used on the server so I had to use https://www.mydomain.com:9443/Login but it all appears to be working fine now and the certificate is also working the way they should with a green lock so mission accomplished.
I guess it will certainly make for a safer environment as well due to the forcing of HTTPS now.
Thanks to all.
-edb