SoylentNews is people
SoylentNews
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: 2) by RS3 on Saturday October 16 2021, @06:52PM (6 children)
Thank you so much DannyB. Some years ago I inherited a Tomcat server, but those websites were being shut down, so I did very little with it. I know much of what you wrote, and thank you so much for the confirmation.
Re. cert: for testing I generated a self-signed one. It's easy. I won't use it (them?) in production because they cause a browser to prompt the user to accept the cert, and that's not a good thing. When I get the mechanism working we'll buy a cert, or get a free one if it's available for this situation.
Yes, I've run through the many tutorials, each of which has some differing approaches. Apache has some "interesting" ways of setting up .conf files and their directory tree, including .htaccess files and their parameters, and I'm just never sure it sees everything. 'apachectl configtest' just gives an okay or not okay, AFAIK.
As I mentioned below, it's mostly that I need a block of time to focus on it and I'll get it. And as AC below said, getting better mod_ssl logging will help. But I don't think mod_ssl is even getting called...
(Score: 1, Informative) by Anonymous Coward on Sunday October 17 2021, @02:33AM (3 children)
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.
(Score: 2) by RS3 on Sunday October 17 2021, @05:20AM (2 children)
Wow, thank you for all of that. Yes, I'm pretty careful and consistent with config files and most of what you describe. But when I get some time to try it again, I'll use everything you've so kindly written, and thank you again.
It seems different Linux distros set up Apache different ways, so that makes following tutorials / how-tos a bit complex, but I got it together and Apache would run, just no response to the https request. I've been doing systems admin and software development for a long time (hw too!) so I can handle it. It's just a bit annoying to try to correlate a tutorial aimed at Debian and derivatives, when I'm running CentOS. But I'm probably about to switch to Devuan, so, well, that first.
I like the idea of separate config file for http and https.
It is a live server with many virtual hosts.
I'm very good at copying httpd.conf to httpd.conf_10-14-21 or some such, and make backup copies.
It might be weeks before I get enough time to focus on this thing. Main job and other critical responsibilities are taking up all of my time these days...
(Score: 1, Informative) by Anonymous Coward on Sunday October 17 2021, @07:30AM (1 child)
I mentioned this to a person I know, she said CentOS doesn't use the standard directory setup of most distros. However, we've (well, she) changed it so it is closer to the standard setup on our machines but that isn't the default. Regardless, setting this up should be easier with Devuan, which does a bit clearer (IMHO) separation of global/module/site configuration by default. And when you do come to that phase, you don't have to do all the TLS stuff at once. Each of those steps is doable on their own without breaking anything that works and can have plenty of time between them.
She also said that if you have a standard CentOS setup, certbot from the EFF can do the TLS configuration changes for you automatically, including the module installation and RedirectMatch. That might be worth a try if you want a safe and usable setup with minimum effort and don't really care to learn step by step.
(Score: 2) by RS3 on Sunday October 17 2021, @05:45PM
Thank you so much! I had not tried certbot and probably wouldn't at the time. I generally don't like, well, haven't had good results from software that tries to write / edit configuration files. That said, I've used many and learned from the outputs, but kept copies of default / previous iterations. A great example is "samba swat". It showed me some things I didn't know about, but it made a mess (which I cleaned up). But I'll try certbot with the new system, whenever I get around to it.
I'm a Slackware guy firstly, but I haven't deployed it live. As much as I like it and am totally familiar with it, I'd hate for someone else to have to deal with it, for whatever reason, and curse me for installing Slackware.
I did not like Red Hat when it came out, and it took a while for me to warm up to it. Acquired taste and all I guess.
Tried and like many others. I prefer to stay away from systemd. Someone here (you?) gave me some great info on systemd, but I just don't like the idea of it, and I don't see how it's necessary or a benefit. I'm good with admin, and I need stability and predictability.
I really like Alpine but like too many it doesn't have good package management (IMHO). So it's on to Devuan, and I think I'll like it.
Thanks!
(Score: 3, Informative) by DannyB on Monday October 18 2021, @04:04PM (1 child)
Here is a tip. Don't just generate a self signed cert.
1. Generate a self signed cert that is used to sign other certificates. In other words, your own private certificate authority.
2. Now using that private CA cert, generate and sign a new cert for your domain.
3. Take the self signed cert (without the private key), and install it in to one or more web browsers within your organization so that those browsers now trust that "CA". If you have a large fleet of Windows boxes joined to a corporate domain, this is easily done to install an internal private corporate certificate into ten thousand PCs.
Now your internal machines will honor your domain certificate and allow real testing before buying a certificate.
Young people won't believe you if you say you used to get Netflix by US Postal Mail.
(Score: 0) by Anonymous Coward on Tuesday October 19 2021, @02:44AM
The best practices now is to use a 3 level CA system. Generate the self-signed cert and add the public part to the trust store. Use its private key to sign the intermediate certificate, split the root key into secret shares and then destroy it. Then use the intermediate certificate to do all the heavy lifting. That way you leave yourself with various outs when compromise occurs, among other benefits.