4 ms·

It's definitely an option, but the question is whether someone who has set up certbot at some point in the past will benefit from it without manual intervention

by pfg 9y ago

It's definitely an option, but the question is whether someone who has set up certbot at some point in the past will benefit from it without manual intervention (as is the case for Caddy). If you're following the standard setup, using the instructions on certbot's website, you'll select exactly one plugin (with each plugin mapping to one challenge type, unless you do something fancy), and if that challenge type goes away, manual intervention is required.

stephenr 9y ago
> but the question is whether someone who has set up certbot at some point in the past will benefit from it without manual intervention (as is the case for Caddy) This whole thread is responding to the author of Caddy saying specifically that people need to intervene or Caddy won't necessarily renew properly. I specifically said in the above comment, that doing a renew in dry-run mode (because a --force-renewal re-uses the existing challenge authorisation my certs have against TLS-SNI) correctly falls back to doing the http challenge. The only "manual" part was that I ran the command - if the certs are due for renewal and the regular cron/systemd timer calls it, the TLS-SNI authorisation will either still be valid, and it will renew as expected, or it will need to re-authorise via challenge, and it will fall back to the http challenge as I just demonstrated, and renew as expected. > and if that challenge type goes away, manual intervention is required If all the methods you chose (e.g. TLS-SNI,HTTP) went away, sure, intervention would be required. But if they all went away, no client would work. > If you're following the standard setup, using the instructions on certbot's website If you follow the standard setup for Caddy you have a 50/50 chance of getting a cert today. Either you accept that people can deviate from the most basic "this is how you can run it as an example" or we stick to the defaults both ways. Claiming "oh but the standard setup.." when this issue requires caddy users to change their freaking init/sevice files is disingenuous. For reference, I use HAProxy + Certbot and a tiny shell script - and it hasn't been susceptible to any of crazy issues Caddy has had just in the last 12 months, due to weird intentional behaviour of the program.
- pfg 9y ago
  > This whole thread is responding to the author of Caddy saying specifically that people need to intervene or Caddy won't necessarily renew properly. No, that's not what Matt said: > Your sites will likely not go offline even if you do not use this flag because Caddy tries up to 2 times per day, 30 days out, to renew an expiring certificate, as long as you keep it running. > the TLS-SNI authorisation will either still be valid, and it will renew as expected, or it will need to re-authorise via challenge, and it will fall back to the http challenge as I just demonstrated This is not an accurate description of how you'd be affected with typical certbot deployments. Two examples: Debian Stretch with apache2. Certbot's website recommends the following command: sudo certbot --apache Currently, this fails with the following error message: Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. Same OS, nginx. Certbot recommends this command: sudo certbot --nginx This causes the same error. Renewal would fail with the same error message; You can find examples on Let's Encrypt's Community Forum if you don't believe me[1]. Is it possible to set up renewal in a way that would cause certbot to fall back to a working challenge? Sure. But it's far from common or even the default. > If you follow the standard setup for Caddy you have a 50/50 chance of getting a cert today. Either you accept that people can deviate from the most basic "this is how you can run it as an example" or we stick to the defaults both ways. Claiming "oh but the standard setup.." when this issue requires caddy users to change their freaking init/sevice files is disingenuous. Again, you're misinterpreting what Caddy does. Renewal will only fail if you're unlucky 60 times in a row, as opposed to 100% of the time for most clients in common scenarios. [1]: https://community.letsencrypt.org/t/client-with-the-currently-selected-authenticator-does-not-support-any-combination-of-challenges-that-will-satisfy-the-ca/49964/4?u=pfg https://community.letsencrypt.org/t/client-with-the-currentl...
  - stephenr 9y ago
    > Is it possible to set up renewal in a way that would cause certbot to fall back to a working challenge? Sure. But it's far from common or even the default. Is it possible to make Caddy deterministically use the capabilities of the ACME protocol to try the intersection of challenges you want to use, and the ACME server supports? No. It's not. The rest is fucking moot. My point in every one of these threads is that Caddy is presented as "it just works" until it fucking doesn't and you have the weirdest shit happening. With regular tools, it's expected that you have a clue what the fuck you're doing and configure it to meet your requirements. Inexperienced people may use certbot and end up needing to do something. Sure. But I don't expect inexperienced people to be managing production environment servers. Do you? You claim Caddy's defaults are better - thats an opinion, but the problem is it's not a "default" it's forced fucking behaviour. You simply can't tell it to operate sanely like you can with certbot + haproxy.

by pfg 9y ago

stephenr 9y ago

> but the question is whether someone who has set up certbot at some point in the past will benefit from it without manual intervention (as is the case for Caddy) This whole thread is responding to the author of Caddy saying specifically that people need to intervene or Caddy won't necessarily renew properly. I specifically said in the above comment, that doing a renew in dry-run mode (because a --force-renewal re-uses the existing challenge authorisation my certs have against TLS-SNI) correctly falls back to doing the http challenge. The only "manual" part was that I ran the command - if the certs are due for renewal and the regular cron/systemd timer calls it, the TLS-SNI authorisation will either still be valid, and it will renew as expected, or it will need to re-authorise via challenge, and it will fall back to the http challenge as I just demonstrated, and renew as expected. > and if that challenge type goes away, manual intervention is required If all the methods you chose (e.g. TLS-SNI,HTTP) went away, sure, intervention would be required. But if they all went away, no client would work. > If you're following the standard setup, using the instructions on certbot's website If you follow the standard setup for Caddy you have a 50/50 chance of getting a cert today. Either you accept that people can deviate from the most basic "this is how you can run it as an example" or we stick to the defaults both ways. Claiming "oh but the standard setup.." when this issue requires caddy users to change their freaking init/sevice files is disingenuous. For reference, I use HAProxy + Certbot and a tiny shell script - and it hasn't been susceptible to any of crazy issues Caddy has had just in the last 12 months, due to weird intentional behaviour of the program.

pfg 9y ago
> This whole thread is responding to the author of Caddy saying specifically that people need to intervene or Caddy won't necessarily renew properly. No, that's not what Matt said: > Your sites will likely not go offline even if you do not use this flag because Caddy tries up to 2 times per day, 30 days out, to renew an expiring certificate, as long as you keep it running. > the TLS-SNI authorisation will either still be valid, and it will renew as expected, or it will need to re-authorise via challenge, and it will fall back to the http challenge as I just demonstrated This is not an accurate description of how you'd be affected with typical certbot deployments. Two examples: Debian Stretch with apache2. Certbot's website recommends the following command: sudo certbot --apache Currently, this fails with the following error message: Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. Same OS, nginx. Certbot recommends this command: sudo certbot --nginx This causes the same error. Renewal would fail with the same error message; You can find examples on Let's Encrypt's Community Forum if you don't believe me[1]. Is it possible to set up renewal in a way that would cause certbot to fall back to a working challenge? Sure. But it's far from common or even the default. > If you follow the standard setup for Caddy you have a 50/50 chance of getting a cert today. Either you accept that people can deviate from the most basic "this is how you can run it as an example" or we stick to the defaults both ways. Claiming "oh but the standard setup.." when this issue requires caddy users to change their freaking init/sevice files is disingenuous. Again, you're misinterpreting what Caddy does. Renewal will only fail if you're unlucky 60 times in a row, as opposed to 100% of the time for most clients in common scenarios. [1]: https://community.letsencrypt.org/t/client-with-the-currently-selected-authenticator-does-not-support-any-combination-of-challenges-that-will-satisfy-the-ca/49964/4?u=pfg https://community.letsencrypt.org/t/client-with-the-currentl...
- stephenr 9y ago
  > Is it possible to set up renewal in a way that would cause certbot to fall back to a working challenge? Sure. But it's far from common or even the default. Is it possible to make Caddy deterministically use the capabilities of the ACME protocol to try the intersection of challenges you want to use, and the ACME server supports? No. It's not. The rest is fucking moot. My point in every one of these threads is that Caddy is presented as "it just works" until it fucking doesn't and you have the weirdest shit happening. With regular tools, it's expected that you have a clue what the fuck you're doing and configure it to meet your requirements. Inexperienced people may use certbot and end up needing to do something. Sure. But I don't expect inexperienced people to be managing production environment servers. Do you? You claim Caddy's defaults are better - thats an opinion, but the problem is it's not a "default" it's forced fucking behaviour. You simply can't tell it to operate sanely like you can with certbot + haproxy.