Background
I manage several websites which have no SSL certificate, hosted on a LAMP shared environment, alongside some that do.
The shared environment has an SSL certificate for all sites, but it's an invalid domain unless connected to with a specific URL that the hosting provider provides.
This creates the uncomfortable environment that any site with no SSL can still be connected to over HTTPS, and be served an invalid certificate (rather than no certificate / no response).
For some reason, google has recently started linking to these non-ssl sites with https:// rather than http:// despite an invalid cert being served. Clicking on this causes a security warning and is probably scaring away 99% of potential clicks.
Question
My question is, given limited server access, what can I do to prevent search engines from linking to an HTTPS version of a website unless there is a valid SSL certificate installed?
Use 301 redirects to accomplish this.
The search bots don't check SSL cert validity in the first place, so they will connect unlike browsers which check validity and show the warning before a redirect can take place.
The bot will see the redirect and update the index appropriately given time.
Example in .htaccess (also works in wordpress):
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{ENV:HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
Related
I use Vue for Front, Laravel for Back, and aws for server.
But we are using firebase hosting to use FCM. In local, requests are sent well from front to back, but not from host URL.
Because we are making a request to the server as http. So I tried to apply ForceSSL to the server, but it didn't work.
If you've had the same difficulty as me, I'd like you to tell me how to solve it.
My error is
Mixed Content: The page at 'https://firebase hosting Url/login' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://my ip/api/login'. This request has been blocked; the content must be served over HTTPS.
it looks like your website is running under http protocol if you have SSL certificate then make sure to install it correctly on your domain
if you already have it then all you need to do is to add these lines to your .htaccess file (if your on apache server)
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE]
useful links:
https://help.dreamhost.com/hc/en-us/articles/215747758-Force-your-site-to-load-securely-with-an-htaccess-file
I have a Spring Boot app and some static files made with Vue on my Virtual Private Server using Apache Web Server.
I have a problem that the cookies from the backend are not set, more specifically, they don't show up in the developers tools.
Locally everything works fine, and it works in the following way:
land on landing page /login
fill in credentials and call /api/login (backend)
in response headers I see 'Set-Cookie: XSRF-TOKEN=ed5479d8-75e0-4a48-affd-e02ded1c17e0; Path=/' and multiple other response headers
cookies show up in developer tools
access arbitrary other endpoint (e.g. /create-pools)
see that XSRF-TOKEN cookie is sent back to the backend
see that the X-XSRF-TOKEN cookie as header is also sent to the backend resulting in a successful call
On my VPS the flow should be the same, but instead:
land on landing page /login
fill in credentials and call /api/login (backend)
in response headers I see 'Set-Cookie: XSRF-TOKEN=ed5479d8-75e0-4a48-affd-e02ded1c17e0; Path=/' and multiple other response headers
cookies DO NOT show up in developer tools
access arbitrary other endpoint (e.g. /create-pools)
see that XSRF-TOKEN cookie is sent back to the backend
X-XSRF-TOKEN cookie is not sent back to the backend resulting in an unsuccessful call
So somehow on my VPS it doesn't use or set the cookies.
Worth mentioning is that in the apache configuration I have:
SSLEngine On
SSLCertificateFile /etc/ssl/certs/SSL_certificate_www_test_com.crt
SSLCertificateKeyFile /etc/ssl/certs/www.test.com.key
SSLCACertificateFile /etc/ssl/certs/www.test.com.cer
ServerAdmin webmaster#localhost
DocumentRoot /home/bart/test/static/
ServerName www.test.com
ServerAlias test.com
<Directory /home/bart/test/static>
AllowOverride All
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.html$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.html [L]
</IfModule>
</Directory>
CustomLog ${APACHE_LOG_DIR}/access-test-com.log combined
ProxyPreserveHost On
ProxyRequests Off
ProxyPass /api http://localhost:8082
ProxyPassReverse /api http://localhost:8082
What I have tried so far, but didn't work:
look into withCredentials properties on XHR call (I have it added, but setting it true by default doesn't change anything)
Manually read XSRF-TOKEN cookie to see if its present. It printed undefined, but it strangely is sent to the backend as:
Cookie: XSRF-TOKEN=ed5479d8-75e0-4a48-affd-e02ded1c17e0; in the request headers (so somehow there should be a cookie)
set domain name of cookie in Spring to test.com (so that it doesn't set cookies to localhost)
set path name of cookie in Spring to /
In proxypass I send /api calls to the backend. The strange thing is that once I manually navigate to test.com/api suddenly the cookies showup (with path /). If I, after that, navigate to another page then suddenly the cookies are there. It seems like I first manually have to access a /api endpoint (which is not a page but an HTTP to the backend) before the cookies show up.
How do I solve this for me unknown problem?
Regards,
Bart
In the end it seems to be resolved by changing the way I call the backend. Previously, I called it using https://test.com/api, but I saw that request that used https://www.test.com/api got the cookies set correctly. Whereas the https://test.com/api calls did not. Therefore, I changed the way I call the backend by adding www.
I have no idea why it works this way, but it seems to have solved the problem. If anyone has any idea as to why, please feel free to add a comment. For now I will approve this as the answer.
Thanks all for considering my question.
Bart
I've pushed my website's DNS through Cloudflare and is now experiencing redirect loops when accessing admin and checkout pages.
The redirect is - http://postimg.org/image/ehq0kjcw1/
My Magento setup
Community 1.9
Cache management has been disabled
Index management has also disabled
Clear all cache
I've followed every steps (except step 4 about restoring visitor IP) mentioned in Cloudflare's article, but I am still having the redirect loop problem. Here are my cloudflare page rules.
This redirect loop problem occurs with or without Cloudflare flexible SSL turned on.
Does anyone has any idea?
If your server supports SSL, you should generally use Full SSL instead of flexible:
https://support.cloudflare.com/hc/en-us/articles/200170416-What-do-the-SSL-options-Off-Flexible-SSL-Full-SSL-Full-SSL-Strict-mean-
This ensures you don't have any weird redirect logic taking place with CloudFlare, since Flexible SSL redirects HTTPS requests to HTTP at the backend.
You could get a redirect loop by having conflicting redirects on your server and/or with PageRules.
Example:
You have one redirect saying send domain.com to www.domain.com, then you have another redirect saying send www.domain.com to domain.com.
If you have access to terminal on your computer, then try running this command to see what is returned in the location field on the URL the error happens on:
curl -v http://yourdomain.com (replace with the actual URL).
I have gotten an excellent and simple answer from Cloudflare support.
I just need to simply use Full SSL instead of Flexible SSL.
Printscreen - http://i.stack.imgur.com/FWl0Y.png
I think my Magento has a secure base URL defined and it tries and redirects to HTTPS when I access a secure page.
I'm trying to redirect all https traffic to http using this in Sinatra
get "*" do
if request.secure?
redirect request.url.gsub(/^https/, "http")
else
pass # continue execution
end
end
However, on a custom domain on heroku, my browser shows me the error:
This is probably not the site you are looking for!
You attempted to reach www.[domain].com, but instead you actually reached a server identifying itself as *.heroku.com.
My DNS is configured with the www subdomain having a CNAME pointing to [domain].herokuapp.com as per https://devcenter.heroku.com/articles/custom-domains
Is this a DNS issue? Is buying a SSL certificate the only way to allow all https traffic to redirect to http, on heroku?
If you were going to use that code then I'd make it a before filter, as that's really what it is.
However, if you've received a request at the application layer (which is where your Sinatra app sits on Heroku) then you need a certificate because the HTTP layer (where the Nginx proxy servers that deal with this sit) has already received the request and will attempt to deal with it as a secure connection but fail/raise an error because there's no certificate. That is the message you'll get if you try and reach an non SSL page/site via the https URI scheme. You can still access the site but the user has to click past a scary warning.
The only way I know of that may work without a certificate (but looking at this answer probably not) is if you had access to the Nginx configuration and did the rewrite of the URL (and probably some headers) there.
I'm developing on Heroku a site with a couple of subdomains. One of them is signup (as in signup.myapp.com) which requires SSL access -- of course! But the rest of the subdomains, such as www, do not require https to access.
The problem is that the client only purchased an SSL certification for signup.myapp.com. This means that, when a user tries to access other places of my site with https (such as https://www.myapp.com), SSL certification does not validate and browsers tell the user that the site could be malicious... not good for branding.
I tried to make the site redirect from https to http, but of course this failed, because SSL was checked before the redirect could be sent.
Is there a way that I can deny access to these places of my site from https, so that users encounter, for instance, a 404 page instead? Or, do you know of any other ways to handle this situation? (the client is reticent to acquire a new SSL certificate, specially a wildcard certificate).
Unfortunately, you need a certificate for each of the domains (or a wildcard one as you mention), see e.g.:
How to redirect https to http without any SSL Certificate
The problem is that certificate is the first thing checked, way before anything else happens. If that fails, browser will typically display "get me out of here!"-kind of notification. There's no built in support for SSL-to-non-SSL transition.
You can shut down https://www.example.com (i.e. make your Web server not listen on port 443), but that of course won't yield a 404, also bad for branding.
With just one non-wildcard certificate, the only thing you can do is put all the pages under that domain. I.e. instead of https://signup.example.com/a/b/c, you need to do https://www.example.com/signup/a/b/c or something along those lines.
On the other hand, you can buy the certificate for under $100/year (or $150 total for 2 years) at GoDaddy:
http://www.godaddy.com/ssl/ssl-certificates.aspx
so, depending on your context, it might just pay off to pay this instead of doing any additional development.