4 ms·

In addition to what was already mentioned, it's also to be polite. Imagine if Caddy and other clients already did what you suggest: Let's Encrypt would suddenly

by mholt 9y ago

In addition to what was already mentioned, it's also to be polite. Imagine if Caddy and other clients already did what you suggest: Let's Encrypt would suddenly be receiving ~50% more traffic during an already-stressful time. When we were first integrating ACME into Caddy, traffic spikes like this were a problem (for other reasons, long since fixed), which we now are very sensitive to avoid.

stephenr 9y ago
The default recommended client does support multi challenge, and from what the logs show, the ACME protocol even handles this without extra load - it returns the challenge modes it will accept. I wasnt aware of this and you arent either apprently. The difference is, I'm not shipping a commercial web server package whose key feature is LetsEncrypt (and thus ACME) support.
- pfg 9y ago
  Caddy's current implementation is more resilient than most other ACME clients in the event of an incident like the one Let's Encrypt is currently experiencing. Typical client implementations (such as certbot, but most others too) are configured to use exactly one challenge type at the time of setup and will continue to use this challenge type for renewal attempts, eventually failing to do so in time if the challenge type remains disabled for more than 30 days (or whatever schedule the client uses). We can argue about the trade-offs of picking the challenge type at random versus, say, trying one and then falling back to another (both approaches have their pros and cons), but that's already more than what you'd typically get from ACME clients.
  - stephenr 9y ago
    > Typical client implementations (such as certbot, but most others too) are configured to use exactly one challenge type at the time of setup Certbot has a preferred challenges flag, which takes an ordered list. Setting it to tls-sni-01,http-01 means it will try to use the TLS challenge first, and fallback to the HTTP challenge. I've tried this myself in dry-run mode (because my existing certs all still have valid authorizations against the TLS-SNI challenge) and it will drop back to http-01.
    - 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...
- deleted 9y ago
  [deleted]

by mholt 9y ago

stephenr 9y ago

The default recommended client does support multi challenge, and from what the logs show, the ACME protocol even handles this without extra load - it returns the challenge modes it will accept. I wasnt aware of this and you arent either apprently. The difference is, I'm not shipping a commercial web server package whose key feature is LetsEncrypt (and thus ACME) support.

pfg 9y ago
Caddy's current implementation is more resilient than most other ACME clients in the event of an incident like the one Let's Encrypt is currently experiencing. Typical client implementations (such as certbot, but most others too) are configured to use exactly one challenge type at the time of setup and will continue to use this challenge type for renewal attempts, eventually failing to do so in time if the challenge type remains disabled for more than 30 days (or whatever schedule the client uses). We can argue about the trade-offs of picking the challenge type at random versus, say, trying one and then falling back to another (both approaches have their pros and cons), but that's already more than what you'd typically get from ACME clients.
- stephenr 9y ago
  > Typical client implementations (such as certbot, but most others too) are configured to use exactly one challenge type at the time of setup Certbot has a preferred challenges flag, which takes an ordered list. Setting it to tls-sni-01,http-01 means it will try to use the TLS challenge first, and fallback to the HTTP challenge. I've tried this myself in dry-run mode (because my existing certs all still have valid authorizations against the TLS-SNI challenge) and it will drop back to http-01.
  - 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...
deleted 9y ago
[deleted]