Hacker News Reader

> 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.

I 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.

Yeah I've done the certbot thing for a variety of servers. I have experienced update barfing. I set up a monitoring thing (the same monitoring thing I use to tell me if my website is down) to tell me if my cert is getting near expiry. The certbot tool I used just did a soft stop-start of nginx, which took I think 200ms or so. Either way, I suspect the startup and renewal time costs are significantly lower than the time cost of writing a blog post to justify not doing it.

And again, this is assuming you start from the premise that you must host your own thing and manage your own thing; if you actually want to zero out this complexity, just use GitHub Pages.

I tend to think that if you are talking to someone and they say "I'm having problem <x>", and you say "Have you tried a, b, c known solutions?", to which they say "I can't do those because I also need <y>", so you say "Have you tried d, e, f known solutions?", to which they say "I can't do those because I also need <z>", the longer the conversation goes on the more it's obvious the person in question is just happy being grumpy. Which is fine. I have tons of different crank views, I can't tell you how much code I've written rather than use something off the shelf because of whatever screws are loose in my head. But it's sort of the price of admission, right? Like, other people are not experiencing any of this stress, the entire problem domain is self-imposed.

Before I used DNS verification, Apache had to be down for a minute so certbot could offer the appropriate URLs itself for the 20-something domains/subdomains I have a cert issued for. Maybe there's a parallelize option I missed?

I am sure there is an Apache module to short-circuit this (i.e. offer whatever verification tokens are needed on top of whatever Apache is serving otherwise), but I personally did not bother.

> And again, this is assuming you start from the premise that you must host your own thing and manage your own thing;

Sure, but that's what the premise is. "Must" is a strong word, but I'd go with "want".

And one can satisfy the "want" without the unnecessary work like HTTPS certs. No matter how minute, they are significant compared to the maintenance burden otherwise.

All I am saying is that it's a perfectly valid position OP has, and that there is more work and maintenance needed even for "automated" LetsEncrypt certs.

Re the first point: The verification is specifically designed so it just involves fetching files and thus can be done through a folder served by the main webserver. Certbot writes the challenge responses in that folder, informs LE that is has done so, the verification fetches them, your Apache serves them. Years ago when I first setup LE I think one needed to configure some of that manually for nginx (or maybe I just didn't trust it and decided to ignore the automatic setup? not sure).

All the arguments against this being extra work are pointing how it's possible to do it (extra work, ain't it?).

In a nutshell, I agree and it's worth it to _me_. It is still extra work :)

FWIW, my Apache is a reverse proxy to multiple VMs for each different service I run, so without pulling out my mod_rewrite skills out, "just serving a folder certbot can write to" is anything but.

> 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

Not really. How would an end user know the difference between the owner rotating their certificates and a MITM?

> 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.

I have been using the webroot option. Minimal web server configuration which I have standardized across my web servers and put into configuration management, and doesn't require the web server to go offline, just a reload at the end to pick up the new cert.

Also I don't update software on running system but will build a new system and replace the old one after testing. All automated.

I took the time to set this all up to make it easier on me in the long run, and it has. To each their own.

Now maybe if they were using some decentralized blockchain DNS (is Namecoin still a thing?) and hosting all their files on IPFS, they would be putting their money where their mouth is.

Heck, why not just use GNU Freenet?

Until that happens, this sounds more like religious fervor than reasoned argument, and this article is one big post-hoc rationalization.

> I mean, we're talking about a task scheduler here.

Not just that, the certbot tooling as well, which can be arbitrarily flaky.

> Is this a Temple OS situation?

And so what if it is? Why shouldn't someone be able to run a website on Temple OS, or a 68K Mac, or whatever, if he wishes?

> 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.

He wants to publish his own site, not engage someone to publish it for him. As you quote below, he objects to outside control.

If one hosts one's site on GitHub Pages, then one is beholden to their rules and standards.

The author can want whatever the author wants, as I say repeatedly, it's just not of interest to me as a reader if the author is backed into a corner by a series of bizarre lines in the sand on his part.

The author is responding to a discourse that says "You should serve your website SSL-enabled" in a passionate enough way to write a blog post about why he shouldn't, and it turns out the reason why he shouldn't is more or less that he doesn't want to. OK. Cool.

The choice to want to control everything (except all the things you don't fully control, like the domain name, the DNS system, and probably the SMTP server) means that there's a little overhead setting things up. This is known. It's not particularly interesting.

>And so what if it is? Why shouldn't someone be able to run a website on Temple OS, or a 68K Mac, or whatever, if he wishes?

Absolutely. Or even a gopher site or a Fidonet BBS.

The technology mainstream moves on, and if you don't stay with it, you have to expect that there will be implications. At this point, the technology mainstream is moving towards TLS as table-stakes.

There's also a higher level point which is that he does whatever the fuck he wants with his website.