Unbind port 80 after acme challenge?


I’m trying to see whether it’s possible for caddy to unbind port 80 after completing the acme challenge?

I’d like to avoid binding unless necessary during the challenge.


It’s not currently possible to configure Caddy to do this.

Given that Caddy uses port 80 for renewals as well, I can imagine we’d be introducing a lot of unnecessary complexity and points of failure by implementing this functionality. For example - what happens if something else binds port 80 in between challenges?

The best practice for Automatic HTTPS while only listening on port 443 would be DNS validation. Otherwise you might consider managing your certificates manually (with Certbot or acme.sh or similar).

I guess the same thing that would happen if anything else failed in the process (acme being down, file permissions changing in the system, etc).

Maybe this is too much of an edge case but it would definitely be nice to have to stop exposing :80 when not in use.

I understand the best practice, this is for a domain which doesn’t have a supported dns provider, and I was hoping to take advantage of one of caddy’s best feature with auto https instead of relying on certbot or whatnot.

Thanks for the answer

To clarify, what happens in this circumstance is that Caddy fails and exits, citing the reason for the failure, so that you can discover and fix the issue immediately. This is an important design decision and a stance that the developers feel strongly about. When it comes to security and automated TLS management, we want any possible gotchas to be up front, no surprises down the line.

If Caddy fails later on, while you’re not there and are expecting it to be running smoothly, we don’t have that option any more. We’d have to hope that you check the email address you provided to LetsEncrypt (assuming one was provided) and notice the expiration warning.

Port 80 will, in almost all configurations, still be in use regardless; it will be used to upgrade clients to the correct scheme and port for the secure site.

I’m not disagreeing with you.

I’m pointing out that there are other ways caddy can silently fail during renewal already, whether it’s something changing on the system (file permissions for the cert directories, etc), or with let’s encrypt (service being down, and so on).
This would just add to that list, and users would expect this since they specifically choose to use this feature.

in almost all configurations

Right, and this would not be an issue since, as you said, in almost all configurations this feature would not be enabled. And for those who choose to use it, this would be a known risk.
For the few who would need it, this would make life much easier though.

No worries - this kind of discussion is quite welcome, and you’re absolutely right, this would join a number of other reasons Caddy could succeed initially but fail silently later.

That said, a few mitigating points help differentiate this case - at least in my mind - from the others you mentioned:

  • I don’t think a Caddy instance has ever gone down due to LetsEncrypt outages, and there’s nothing we can do if an administrator actively sabotages the TLS management by removing required file permissions for $CADDYPATH.

  • I think running a listener on port 80 for some other service is far more likely to happen negligent of Caddy’s renewal requirements than changing the TLS assets’ permissions would be.

Lastly, I really don’t see why the developers should implement this, and implicitly encourage it, when a savvy administrator (and importantly, one who understands the implications of this setup) could simply add a cron job to certbot renew && pkill -SIGUSR1 caddy every other month.

EDIT: You’re also welcome, of course, to post a feature request to the Github repo: https://github.com/mholt/caddy - you’ll likely get a more direct response as to whether they’d consider implementing this.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.