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: 1, Informative) by Anonymous Coward on Sunday October 17 2021, @02:33AM
Unless you absolutely have to have it, you should disable per-directory configuration overrides. They are an accident waiting to happen and can hurt performance.
The way that makes sense to me is to put all global options in the global configuration files, all module configuration in the module configuration files, and the site configuration into the sites configuration files. If you keep the scopes distinct, it makes sense. Something like logging or default permissions should be set globally. Most TLS options should be set at the module level. Then you should have at least two site configuration files, one for HTTP and one for HTTPS, that set the options specific to them like DocumentRoot or RedirectMatch.
A final note is that following different tutorials with different approaches is usually a bad idea since your changes get spread around many different files. What I would do is try to get your configuration as close to stock as it is possible to do safely first. Then I would enable mod_ssl and mod_alias with the appropriate symlinks. Make sure they get loaded at startup. Then I would add a site config file to your available directory and do the basics of having all URLs aimed at that virtual host redirect to the HTTP version. That will teach you how to get TLS going and how to write the appropriate RedirectMatch setting. Once you get your TLS setting hardened enough in the module config and the site working, you copy the DocumentRoot or however that is set up to the HTTPS site config. Once that works, you add the redirect to the HTTP site config and get rid of the DocumentRoot. The benefit of doing it this way is that you can get each part of the set up step by step without endangering the rest of your website and on your own time. I probably made that sound too easy and glossed over steps, but you can always ask.