Comment by stephenr | Hacker News Reader

Comment by stephenr | Hacker News Reader

Parent Full thread

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

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

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

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

Very, very few ACME clients have a renewal mechanism that supports automatic fallback to a different challenge type. I know a couple and the only one I can think of is certbot, and even there that's only true if you use the standalone or manual plugin (the others don't support "--preferred-challenges").

However, if your question is "Can I make Caddy use the exact challenge type I want it to", then the answer is yes, as you can guess from the "-disable-tls-sni-challenge" flag. This is what most clients will let you do. No one is saying that those clients can't renew with manual intervention.

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

You're changing goal posts.

> With regular tools, it's expected that you have a clue what the fuck you're doing and configure it to meet your requirements.

Part of knowing what you're doing as a developer is knowing that you either have sane defaults or stuff is going to break for a lot of people.

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

Are you implying anyone using the default instructions for certbot is inexperienced?

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

If you think you can do better with your own approach, by all means do that. Most people are not PKI or ACME experts and won't have the necessary knowledge to make all the right calls, so they're better off with a "managed" solution like Caddy.

To be clear: This is an edge case and I'm in no way saying the certbot team is incompetent because they did not foresee this scenario and handle it as part of the default setup. It's just silly to go on about how terrible Caddy is when they happen to have a mitigation in place.

> Very, very few ACME clients have a renewal mechanism that supports automatic fallback to a different challenge type. I know a couple and the only one I can think of is certbot, and even there that's only true if you use the standalone or manual plugin (the others don't support "--preferred-challenges").

And that's why I use and recommend certbot in standalone mode.

> You're changing goal posts.

No, I'm trying to explain my overall point.

> Part of knowing what you're doing as a developer is knowing that you either have sane defaults or stuff is going to break for a lot of people.

Right, but in this case Caddy doesn't have "defaults" that experienced dev's can change, it has "this is just how I fucking work".

> Are you implying anyone using the default instructions for certbot is inexperienced?

I'm suggesting that anyone whose sole research into how to use ACME generated certificates in production is "what's the quick start for certbot say?" is inexperienced.

> so they're better off with a "managed" solution like Caddy.

Managed, except that they have to keep intervening or updating to a new build to restore functionality because it manages things like a drunk on a snow mobile.

> It's just silly to go on about how terrible Caddy is when they happen to have a mitigation in place.

Caddy requires a 'mitigation'. Certbot can and is deployed with a configuration that doesn't require any mitigation. It's just silly to keep claiming Caddy's approach is "the best" when you require a mitigation.

Reply on news.ycombinator.com