3 ms·

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 te

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

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