In general, the person who tells you something is wrong with your website is your friend. But, sometimes it opens up a bigger can of worms!
Yesterday, such a friend emailed me asking if I was in the middle of fixing my hacked website. I believe they wanted to link to it. That was quite a mystery, because I have a new site on a new host, that has not been hacked.
BACK STORY 1: Yes, it was hacked many years ago. And when that happened many years ago, I deleted my existing site, took some time to analyze the hacker’s code and rebuilt a static site on my original web host with my findings. That is I replaced my hacked site that has been more of a marketing tool with an ugly site that was purely information about website hacks. No, I wasn’t happy with how my site was. And, like many other business owners, I just kept pushing the work off to a later date.
SO TODAY, a month later after restarting, someone tells me that they are seeing my old site, not my new site. But. that shouldn’t be. It’s been long enough that browser caching shouldn’t even be a problem. So, I turned my attention from adding content and tweaking the theme to determining what the barriers are for people trying to reach the site.
First, I found out that my site is throwing the privacy/security error from the screenshot below. I actually ran into this same issue. Actually, I ran through this issue by setting a security exception. That is, I avoided fixing it … once again, pushing something off to later.
This message is not a critical “your site has been hacked” message, but a notice that the viewer is using an https address when you don’t have a functional secure certificate in place. In most cases, if the viewer uses http:// the error page won’t show. But, does this matter? Yes, this is a secure certificate problem. I thought that the https address should work just fine because my site is hosted on SiteGround. Supposedly there is a secure certificate for all SiteGround sites. so what’s going wrong? Previously, I noted that the service is there, but I didn’t pay it much mind. It looks like it’s time to dig in further.
The Let’s Encrypt screenshot brings up an important topic: each certificate is attached to a single domain name. The protection is on the name, not the website files.
BACK STORY 2: In the debugging process, I checked my Support Tickets in SiteGround to see if I had had any problems before. And, indeed there was a problem in March of 2017.
Me: What’s with this secure certificate blocking my site? I didn’t ask for a secure certificate and this is someone else’s secure certificate.
Support: As I see the Home and Site URLs have been set to https:// links. I have updated them and you should be able to access the site using http://181.224.138.12/~catalys0 URL.
Could you test it on your side and let us know in case there are any other questions or issues?
The problem here is that when you first set up hosting, you are generally working with a temporary address until you have a site that is good enough for the public to see. Then you “aim” your domain name at the site, and you no longer use the temporary address. That is why there is that strange addres swith numbers, instead of MontanaWebmaster.com. The secure certificate was on a domain name, not that temporary address, so the server kept reverting to https when there was no https (secure certificate) on the temporary address. So, they took it off … which is one of the reasons why I ended up with a second problem!
SO WHY ARE THERE TWO CERTIFICATES LISTED IN THE IMAGE ABOVE?
The Let’s Encrypt image above shows that the secure certificate works for the domain name with either www or without the www. The www is actually a “domain”. That means that the type of web resource is a website and it needs a web server to deliver. That is a different service from say, email or ftp, which each have their own domain and server type. Taking that a step further, you need a secure certificate for both. SiteGround’s certificate that comes as part of your hosting package includes both.
SO NOW WHAT?
Like most of the posts on this site, this post started as a Facebook Post. I was very surprised to see a reply directly from SiteGround. That means that they are watching social media closely. That is a topic for another post, but here is their reply:
“We checked on your site and it seems that it’s pointed to us and added to Parked domains. The main function of that is to redirect the domain to the main one for your account. Currently it only needs an installation of an SSL certificate to avoid the error message you are getting.
The SSL certificate itself is naturally installed on the domain name. SSL stands for “Secure Socket Layer” and what it’s main function is is to authenticate the data being sent between a browser and a web server. That being said, the information output from your site’s files is indeed authenticated by the SSL certificate on the domain name.
The error message you see is a browser warning that comes up when a website is trying to establish a secure connection without the presence of an SSL. It can easily be avoided by making sure that:
– your domain is pointed to us
– your domain is added to the cPanel
– an SSL certificate is installed from your cPanel-Security-Let’s Encrypt …”
In any case, I believe that the problem is now fixed. You can tell because the little lock that shows in the browser is locked!
But, that wasn’t actually the problem that the reader meant. In fact, there are two more problems …
Chapter 2 of the Problem