4 ms·

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

> 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 ago
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.
scoopertrooper 5y ago
> 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?
notafraudster 5y ago
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.
- necovek 5y ago
  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.
  - detaro 5y ago
rascul 5y ago
> 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.

nerdponx 5y ago

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.

scoopertrooper 5y ago

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

notafraudster 5y ago

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.

necovek 5y ago
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.
- detaro 5y ago

rascul 5y ago

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