Back in March I asked you guys if I should put SSL on my mcgrewbooks.com site, since it appeared that it would raise my hosting cost by $25 a year, and there was no technical reason to have it; there is no personal information collected whatever.
I gave a lot of thought to the comments for months, and yesterday decided to go ahead and spend the money; I just put three grand on my mortgage principal. So I went to R4L’s web site to find where I could add SSL. I couldn’t find it.
However, their help is actually a Canadian who helps through text chat, who informed me that paid hosting came with SSL, I simply had to turn it on.
Well, it wasn’t that simple, as they’re upgrading their tools and I ran across a couple of 404s. But I finally found the correct widget to click, so the unnecessary lock is no longer broken.
My other site still has a broken lock, but it’s a “free” site. Registration there is $15, but you get ten megabytes of hosting. Those are the kind of site that an extra $25 buys SSL, and you might as well pay for hosting. It isn’t much more, and it isn’t hard to fill ten megs. Almost all of the images at mcgrew.info are either on Wikipedia (which reminds me, I should donate again) or mcgrewbooks.
I wish I would have known that five years ago! But I’m still more than happy with R4L.
Since R4L is Canadian, whose internet laws apply? America’s? Canada’s? Both? Neither?
(Score: 3, Informative) by DannyB on Thursday October 14 2021, @06:13PM
Unfortunately, I don't use "Apache", but I use "Apache Tomcat", which is a Java "application server" (more than a "web server"). Tomcat is from the overall Apache project and of course Apache 2 license.
Another thing I had going for me. I was able to devote my full time and attention to this matter while getting paid to do so. That helps a lot right there.
Just googling, there seems to be no shortage of articles on setting up Apache with SSL/TLS.
You will need to have a certificate for your domain. From a Certificate Authority (CA) that is recognized by all popular browsers. (There is a whole process in getting that certificate.)
The following is a lazy and loose summary.
The certificate comes in a container. There are various types of containers. A common one is PKCS12. There is a password you need to "open" or "peek inside" the container. (Sort of like a zip file.)
The container will have two basic elements. (1) a private key, and (2) a certificate for your domain.
The private key is the secret you want to protect. Since the container file requires a password, you really want to protect the password to your certificate container. The valuable secret key is too long to memorize or write down. Without going into detail, the secret key along with presentation of the certificate enables a web browser to verify that your web site really and truly is in possession of the certificate. Also your content is encrypted in both directions. It is also in principle possible for the browser to use a certificate to prove who you are to the server. The common case is to prove who the server is -- to know that you aren't giving your credit card info to someone pretending to be Amazon.
You can relax and be sure that you are safely giving every last private detail of your life to Google, and not someone claiming to be Google.
I don't know that I can give you much help, except for Tomcat, which I know pretty well. I know some neat tricks with Tomcat, like setting multiple server instances on different ports on a single OS. Each instance can be quickly pointed to a different Tomcat software version, different web content, and different Java version. So I could make some changes in a script, and make "server 11" point to a different Java runtime, different Tomcat version, and different content, with just a few seconds downtime. Multiple instances can share a common Tomcat software, and common Java software to avoid redundancy. It is also easy to download a newer Java and test it out on one of the servers to make sure everything works -- or to quickly switch it back.