Removing an SSL certificate without breaking links - .htaccess

Over the course of the last year a site I maintain with a payment gateway has stopped taking payments or collecting any user information. Seeing an opportunity to save a few bucks, we let the SSL certificate lapse.
The problem I am facing now is that Google and other sites have linked to the https version of my site. Whenever any of these links are visited you, rightly, get a security warning.
I added the following to my .htaccess:
RewriteEngine On
RewriteCond %{HTTPS} on
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}
But I'm still hitting the warning page every time I visit the site via an https link.
How can I get around this? In my head, for it to be failing the .htaccess file is being read after you visit the site, but Chrome is blocking the page before that stage – is that correct? If not, it may just be that I have a typo in my htaccess file.

Any kind of redirection is done after the TLS handshake, this means you get the warnings before the browser even gets the information that it should redirect.
And to anticipate a typical follow-up question: fiddling with DNS (i.e. CNAME etc) will not help either.
That means that you either accept the warnings about the broken certificate or you get a new certificate for your site.

Related

Why does the insecure version of my website still exist on Google when I've purchased an SSL certificate?

I've recently used Heroku to purchase an ssl certificate for my website (using free dynos). I'm relatively new to web programming and this is my first time trying to get a website secure. I've run into multiple problems but my main one is that when I type into Google the name of my business (jsm websites.com), I click on the link to my website but it sends me to the insecure version of my website (just http, not https).
I'm really confused as to why this is happening, as the ssl certificate has been issued without problems and also I can access the secure version of my website when I manually type into the url bar "https://www.jsm-websites.com". Also, some of the links on google that link to additional pages on my website (such as to the about page or the discover features page) send me to the secure version of my website.
Is there a way to just delete the insecure version of my website so that google will just send people to the secure version? Or do I need to do some fancy coding to direct people there manually?
Thanks for your help, if I've not explained myself well please send me a question.
P.S. I am using goormide as my development environment and the url I am using is www.jsm-websites.com.
Just put below code in your htaccess , Your domain is secured but google will read and takes time to crawl , till you don't put manually you need to put below code in
.htaccess
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.domainaname.com/$1 [R,L]

my site hijacked, added url on my site and can't be redirected

My site hacked and they add url with string "bitsofev" for example:
http://example.com/~bitsofev
http://example.com/~bitsofev/apple.de
Check here for real sample
https://www.google.com/search?safe=off&q=bitsofev&nfpr=1&sa=X&ved=0CBsQvgUoAWoVChMI7LnMiOvIxwIVQpGOCh1T2wC6&biw=1570&bih=899
I tried to redirect it to homepage with htaccess but not working
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^(.*)~bitsofev(.*)$ http://example.com [L,R=301]
</IfModule>
I tried the same code to redirect other string and it works fine, but not "bitsofev" string. weird.
Best I can do for this is to block on robot.txt but its not solving the problem. What can I do for this?? Where can I fix the original problem? How to redirect it to homepage if I can't find the source?
Additional info: I searched on MySQL db, and I can't find 'bitsofev'.
I have a similar problem. Someone may have added the "/~bitsofev/apple.de" url to my site. A web analytics app track visitors and the content viewed at my site. Like you I don't have many users. Originally I thought that the "/~bitsofev/apple.de" was first accessed sometime last month. I originally also noticed that one of the user at my site registered at nearly the same time. My first thought was to temporarily deny this user access to signing into the site (and interacting with mysql db) while I investigated if this user uploaded a malicious file to the mysql db or exploited some error in the code that I was not aware of. However, I subsequently discovered (I hadn't been monitoring it regularly) a message from google regarding the url "~bitsofev/apple.de" in my admin inbox which predates the web analytics data and the user's registration that I originally thought may have been suspicious.
I will let you know everything further that I ascertain.
I meant to post this as a comment and not an answer. I apologize.
Add the the following to your .htaccess file:
RewriteCond %{THE_REQUEST} ~bitsofev/apple.de($|\ |\?) [NC]
RewriteRule .* - [F]
This will block (403 error) the file and url from being accessed. However, it wont specifically correct the problem.
I believe that was is really happening is that you are using shared hosting at Hostgator and IP 108.167.182.250 / 108.167.182.251
bitsofev (the owner of the site http://bitsofeverything.net/) is another user on the Hostgator shared hosting.
For example, go their website and after .net/ type in the tilde "~" symbol and the your user name (your hostgator user name), e.g, ~username
If I'm correct you'll then see your own website. You can then add a / and folders/files and see those, as well.
This is because Hostgator enables (by default) mod_userdir (Apache server).
The only part I don't understand yet is the apple.de because it doesn't appear to be a folder or file at bitsofeverything.net/
At any rate, I've been writing about this for a couple of months (trying to understand it better) at:
Justinbailey.info: What is /~bitsofev/apple.de added url? Hacked, hacker hacking.

SagePay fails when forcing https

I'm using the following in my .htaccess to force https on;
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://%{SERVER_NAME}/$1 [R,L]
However this seems to cause SagePay to throw a 5003 error and a 500 http error.
The site has a valid SSL and was just installed yesterday and if I comment out these lines it works correctly with SagePay. MY callback pages are linked as https so SagePay redirects back to my site with https on so it's not as if SagePay is looking at the address and sees that it's being changed.
I don't have to force https, it won't be the end of the world, but I want to do so for the obvious benefits of https. Am I doing anything wrong, is there something I can do to fix this problem and keep forcing https?
After contacting SagePay support directly and looking at their logs for an example transaction I was able to see that our callback url (that was sent along with the post request to SagePay before the user even got to the SagePay payment portal) was manually set to be http rather than https.
This meant that when SagePay tried to post back to our website to see what to do next it was using an http url which would then have been redirected via our htaccess rules.
I can only assume SagePay's security considered this as tampering or something like that and considered that the transaction was not safe.
After manually changing our callback url to https, everything works as expected.
5003 Sage Pay Error Code
ERROR : Internal server error.
Explanation: If you receive this message, a code related error has occurred on the Sage Pay systems. This could have been caused by the information posted to the Sage Pay server or by an issue with the Sage Pay server.
Solution: Please reveiw the information your server is posting to the Sage Pay server. If you are using FORM integration, ensure the encryption password is correct and casing correct as this error can be returned if incorrect. If you are unable to identify the cause, can you provide the TxID so Sage Pay can view the transaction logs? Transaction logs are to be less than 72 hours old.

forcing ssl for all embedded links using htaccess to tackle insecure content

I am trying to enforce SSL on a folder (blog admin). That part is fine - all pages are SSL, but the site is generating error messages for insecure contents on the page. I can go after all those links individually, to enforce SSL on the links.
I was wondering if that could be done through htaccess alone?
This is what I have done for SSL enforcing on the admin folder:
#forcing https for admin folder
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteCond %{REQUEST_URI} admin
RewriteRule ^(.*)$ https://mysite.com/blog/admin/$1 [R,L]
How can I convert all the non ssl links to ssl on the same page ?
Addition:
1) I am using wordpress 3.6 with different plugins that come along with it. Only the admin areas is SSL, and the rest of it, other than login page (that is outside of admin is also SSL) are non SSL (for example the Blog feed for the end users).
2) A few of insecure contents are coming from my own site, but then there are others which are coming from the plugins I am using. For example disqus commenting system, and flickr.
3) I can force the internal links for images, css, and jscript by simply using 'setting for permalink' on wordpress (noticed the url was provided as http and not https). Similarly, I can locate and fix the other links like this one:
The page at https://mysite.com/blog/wp-login.php ran insecure content
from
http://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js?ver=3.6
4) The issue is:
If I use permalink setting, then the blog links are created as https
instead of http, and that breaks the plugins I am using for the non
SSL pages, for example disqus comment feed don't show up on the blog
page. Secondly, The painful process of fixing all the non ssl links.
Also, I can always miss out on some of them, since I am doing it
manually. It would be really helpful, if I could enforce SSL for all
these non SSL links using htaccess, perhaps the only easy solution.
Rewrite rules (which are in in fact redirections, when it's about HTTP to HTTPS) won't help, since by the time the initial plain HTTP request reaches the server, it's too late.
It's the links on the page you serve that must be addressed. This is generally up to the application (e.g. your PHP/CGI applcation) running on the server, not up to the server itself. The server would need to be able to process the content of the responses it sends to replace these links, not just redirect the requests (like mod_rewrite does).
mod_proxy_html (distributed with Apache 2.4 or separately in earlier versions) is a module that can to in-depth processing of the response, but I'm not sure whether it can be used as a post-processing tool for PHP running on the same server, to rewrite the links it sends.
Of course, this won't fix links to external resources that are not available via https:// anyway.

.htaccess RewriteCond for https

We have our site setup and would like to have a secure members area. (e.g.: https://www.abc.com/members/).
Our host provides us an SSL URL to use for free though it isn't very pretty (www1234.sslurl.com/abc/members/).
Is it possible to use https://www1234.sslurl.com/abc/members/ and rewrite the URL to read as https://www.abc.com/members? If so, I'd appreciate some help with the rule to do this.
Note: This is NOT for a shopping cart and we aren't storing credit cards, or social security numbers or anything sensitive like that. We just want to provide users with a secure browser connection when logging in. Is rewriting the URL unethical?
Added details since someone voted to close my question though I'm not sure why. This is a valid question and is tagged appropriately.
================== SOME CODE I'VE BEGUN WORKING WITH==================
RewriteCond %{HTTP_HOST} abc.com
RewriteCond %{REQUEST_URI} !abc/
RewriteRule ^(.*)$ abc/$1 [L]
Does this look right?
Even if there was a way to do this (and I don't believe that you Apache supports such a redirect), the browser would likely complain anyway. Typically SSL certificates only work for domain.com and www.domain.com. If you try to access that certificate using a different URL, your browser will give an error about the certificate not being trusted.

Resources