Update on Apache NonSSL and Share Servers Solution

Some months ago, I wrote an article on the difficulties I was having due to my hosting an SSL site on a shared provider server using a single SSL site to host multiple domains belonging to many different customers. Visit this LINK to get the details.

I coined my own term of “Jekyll and Hyde SSL Bug” to describe the issue with these shared servers and the SSL problems that occur on hosted sites. This resulted in a new web site to document the problem in further detail, calling out the industry and Apache for having created this issue in the first place.

The upshot is that while my first solution works for preventing my site from being visited by different domain URLs, it does not completely solve the problem of different indexing engines from cataloging content, effectively bypassing my solution. I was still seeing my site pages showing up on some sites and theorized that index engines may be able to index content even with the SSL mismatch in place.  My original solution had solved MOST of the issues, but not all of them.

The content snapshot below illustrates the continuing issue:




Again – to reiterate: My theory is that Google and other search engines may completely ignore SSL mismatch warnings and index the content irrespective of the mismatch. That is unfortunate and illustrates yet another potential problem in how the web indexes things. I’m not completely sure this is a fact, but I realized that a solution might be in order if I could tell .htaccess to use an alternate robots.txt file for domains that were not my own!  I came up with the following .htaccess code to solve the issue:

# Prevent robots.txt execution from unwanted domains from indexing. This should remove any sites from indexing by telling the relevant servers to stop  indexing anything OTHER than afterburner1.  – Rule installed 3/8/2018 – check again in one-quarter to check results.
RewriteCond %{HTTP_HOST} !^(www\.)?afterburner1\.com
RewriteRule .* noindex-afterburner.txt [L]

I created the noindex-afterburner.txt file and populated it with the following:

User-agent: *
Disallow: /

Voila! I tested the site and all appears well. Now to wait on things and how it goes.

I’ll report on how well this works and if the indexing issues disappear over the next few months, I’ll consider this a final success.

Apache SSL and Share Servers problem with nonssl sites

Last October, I ran into a pretty big set of problems with all of my web sites and this necessitated a complete re-think of my site layout and methods of publishing content.

During this process my entire site was moved to a new IP address and my existing SSL site here on Afterburner1 made the journey with no troubles… Or so I thought.

I am pretty careful about analyzing my logs and I noticed a sharp uptick in traffic and after a few weeks, I realized that there was a problem. I couldn’t figure out what was causing all these visits to my site and they were all very short visits.

I suspected spammers and tried a few things to no avail. And then, quite by accident, I discovered that my site content was showing up on all sorts of web sites, coincidentally ALL with the same IP address my site  has when doing an nslookup on them.

As you can see below, my content was showing up on sites that had nothing to  do with mine. I coined the term “ghost content” since the page were NOT being hosted with this content. It was only showing up on Google.

What I discovered was that my provider had the issue (and it seems to be a common theme with many other hosting providers as well). It seems that the shared servers like the one I reside on, host more than one client, all off a single I.P. address. And while this is quite normal, what was NOT normal was that I had an SSL certificate that was the first one on the list of sites for that particular server.

My provider decided to tell me after some days of prodding as to what the cause was. It seems that if an web site does NOT use SSL certificates on a shared server, then anytime someone or something like a search engine visits that site with https://somesitename.com then they get directed to the alphabetically first VALID SSL site on the shared server. In this case, it was MY site – This site you are on.

And the fun wasn’t over. My provider informed me this morning that the ONLY way to fix this was to have me shell out $24 to go to a separate IP address on my OWN server. I was more than angry at this exchange because it meant that I would leave the server to solve MY problem and it would be dumped on someone else and the cycle would continue.

I grumbled about it and then decided to tell them to go fly a kite. And I decided to think through the problem. After running some tests, it occurred to me that when visiting one of these site on the same server as me and then using https to get to their URL, that I was able to see their hostname when it got dumped into my site root.

So, I went and made a new domain at 1anossl.net and created a landing page with information about the problem. But I needed to do something in .htaccess and decided to fail ALL https requests to my site that did NOT use my domain.

I created the following rule to be placed in my site .htaccess file:

# Send all hosts that do NOT match my address to the purgatory where they belong
# This is done because my SSL cert is the first one on the shared server. So,
# These people will be sent to the 1anossl.net page.
RewriteCond %{HTTP_HOST} !^(www\.)?afterburner1\.com [NC]
# Return a failed request and tell the source that the content is gone "G"
RewriteRule .* - [F,G]

So, after some work to make it all work as intended, I released the code and voila! Any http host on my shared server whose site is visited with https is rewarded with a failure to connect to the page via error code 410 as a result of the RewriteRule I installed.

Note: As of March 2018, I realized I needed to add some additional code. Visit this page to see the new additions.

To learn more, visit 1anossl.net  and if you happen to be on a shared server and are seeing the same issues I was having, you now know what to do! Contact me if you have any questions!

— Jon

SSL issues with at least 30 sites directing to mine

Note – this has been solved with my own initiative since my provider was not going to fix this without charging an arm and a leg and to pass the problem on to the next site owner with SSL on the shared server I was hosting on. I fixed the issue! See the article on how I did this and the new site to catch these non-ssl sites that end up accidentally visiting my site root by directing them to http://1anossl.net/

If you are from one of many sites accidentally getting to my site home page, listen up:  My provider has a mis-configured server hosting my site and many others and it’s creating all manner of issues for at least 30 sites.

My provider is aware of the issue, but sent me a letter after I opened a ticket and basically said I needed to buy ALL OF YOU each an SSL certificate rather than accept that THEIR SERVER IS MISCONFIGURED. It’s not going to happen. Nothing personal, but I’m not buying all of you an SSL cert, but I am trying to help and get you aware of the problem by forcing the issue to the fore-front.

The issue is that for SSL connections to your sites, somehow my SSL certificate is being pulled rather than the default one that is supposed to be provided by my provider.

I’m at the end of my tether since my Google results are completely screwed up and I’m getting increasingly angry at the indifference being shown with this since I started asking for assistance.

My site was recently moved to a new server and when this happened, it seems my SSL cert is now the main cert for all of you. It’s pretty obvious that there is an issue, but I’m getting nothing but crickets from the provider and since they won’t fix it, I’m going to make this the first thing people see when they get in to my front page for Afterburner1.com

So – Here is what to do: Open a ticket with your provider support and complain.  Cite this article. I’m making changes on my site to make sure everyone sees this and any 404 page errors also get directed to this post to the word gets out. After all, if they are going to make me the heavy here, then I get to call the shots on the traffic until this gets repaired.

Again – this is beyond my control to affect the mis-configured Apache server. But at least I can point this out very publicly and hopefully get someone’s attention at our provider. I’m trying to be nice in all of this, but to be ignored for two days as of this writing is now getting old and I have to do something not only for myself, but to help all of you who are affected by this.