4 ms·
A lot of the complexity the author is worried about is brought on by iconoclastic choices. > Code exists for authomating [sic] [LetsEncrypted renewal certifica
by notafraudster 5y ago
A lot of the complexity the author is worried about is brought on by iconoclastic choices.
> Code exists for authomating [sic] [LetsEncrypted renewal certificates], but when I last checked, it did not run on my hardware platform
I mean, we're talking about a task scheduler here. *nix and BSD and MacOS have Cron. Windows has a task scheduler. Every cloud platform has a mechanism to schedule tasks. Is this a Temple OS situation?
But if minimal complexity is what the author wants, they should consider building a static site and deploying it, say, using GitHub Pages, which supports SSL out of the box right now.
> Lastly, as the operator of a personal website, I object to any outside control. I run my own website on my own server for exactly this reason.
So then let's dispense with the notion that HTTPS is adding complexity and get back to the actual point here: potentially well justified neuroticism about having everything under your control is leading to additional complexity. That's fine. Just own it. The whole thing boils down to "I don't want to do HTTPS and I don't want to let someone else do it for me because I don't want to and that's what I want". You do you, dude.
> A TLS certificate is issued by an organization that is not controlled by website owners, website developers, or users of the Internet. That means any time the issuer wants to raise requirements or fees for issuing TLS certificates, he is free to do so.
Turn off your certificate when that happens? Unless you do pinning or HSTS you have no obligation to use HTTPS in perpetuity just because you use it now. If it was someone who wasn't familiar with system administration I'd appreciate that maybe they don't know how to set up their webserver as such, but given that this is a person who's chosen to run their own.
I'm actually not really sure why even this parade of horribles would be coherent. The author has a custom domain for which they pay a registrar. If the registrar raised it prices, he would have to migrate to another registrar or allow the domain to deregister or pay the additional fee. Everything on this earth is transient, it's OK, be at peace. If anything I'd be more interested in a parallel blog post that says "Why I ran my own domain registrar rather than give someone else $10 USD a year for a custom domain" -- that'd actually be the kind of adorable crankery I love to see.
I do get wanting to internalize the locus of control as much as possible, but at some point -- running your own email, running your own domain registrar, issuing your own SSL cert -- the level of complexity leaps up to the point that almost no one does. Which is totally fair! But also not a big deal! It's OK to use external services.
Oddly I actually agree with the author about the underlying point that HTTPS is not really in a cosmic sense necessary for every little domain, but because it's trivial to implement and free -- even notwithstanding engaging any of the ideas about privacy and surveillance that militate towards HTTPS -- I don't understand the objection.
- necovek 5y ago> I mean, we're talking about a task scheduler here. *nix and BSD and MacOS have Cron. Windows has a task scheduler. Every cloud platform has a mechanism to schedule tasks. Is this a Temple OS situation? Are you running your own personal web site and have LetsEncrypt certificates set up? It's not all roses, and most obvious tools like certbot would frequently barf on upgrades or what have you when run from a cronjob. And you need to stop your web service for the duration of the "verification" or switch to DNS-based verification, which is not supported by all DNS providers. And I am sure there are different tools to integrate into your reverse proxy so you do not have to stop the service... But just figuring all this out is additional complexity, and there is regular maintenance work involved. It's not hard, but for my personal websites, other than dealing with certificates and pushing new content, I don't need to touch them for months or years even. Thus, even though I do invest time in having Lets Encrypt certificates on my personal server, I fully buy their "complexity" argument. It is the most time consuming part of my setup. > ...about having everything under your control is leading to additional complexity. That's fine. Just own it. The whole thing boils down to "I don't want to do HTTPS and I don't want to let someone else do it for me because I don't want to and that's what I want". You do you, dude. There is another problem with "I want to control stuff" argument: DNS is, ultimately, not under their control either. I, personally, hand over reins of DNS and certificates to "other parties", and draw the line there. Still, one can use self-signed certificates to keep full control, and yet allow conscientious users to be susceptible to tracking/MITM only once per browser (or those extra careful who really love this web site could simply trust their CA, though it's unfortunate no browser allows CA-trust to be established per domain IIRC). The validity date can be pretty far in the future so the maitnenance burden is non-existent (unless your CA cert or private cert leaks). That's a suggestion I'd make for them.
- nerdponx 5y agoI do run my own Web servers on dirt cheap VPS systems, with Certbot on a Systemd timer. Under Debian Stable at least, I've never had an issue, across multiple major versions. That, and Borg backup. The hardest part about setting up a new machine for me is remembering the incantation to append my SSH public key to the authorized keys on Rsync.net. I never think about Certbot. Then again, my needs are very simple. Maybe with more complicated set ups, you have issues.