4 ms·

It's still a really nice web server. Easy to configure, incredibly reliable, twenty years of security fixes under its belt, endless docs/info available for it o

• mholt 9y ago
  The concerns about Caddy handling an ACME server outage are not really well founded these days, because: 1) Caddy has the most robust OCSP implementation of any web server. It caches staples locally and refreshes them halfway through the validity period so it can endure days-long OCSP responder outages. 2) Even if a certificate needs to be renewed while the ACME server is down, Caddy can endure 2-to-3-week-long outages of the ACME server because it renews 30 days out from expiration and tries twice per day until it succeeds, logging its actions along the way. And because Caddy is written in Go, memory leaks like what Apache suffers are much less likely, if not impossible. (Source: I implemented it.)
  • stephenr 9y ago
    > 1)... Two calls to OpenSSL and a few lines of shell script will fetch staples from LE whenever I want (ie more often than your defaults that have caused problems before) for HAProxy to serve. How's that for robust. >2)... great so you're as reliable as.. any other LE client that tries to renew before expiry, but without the ability to choose when to renew certs?
    • mholt 9y ago
      1) Caddy has never had OCSP outage problems. When LE's OCSP responders went down for a day a few months ago, Caddy was the ONLY server that kept sites online (unless nginx was explicitly configured for it; almost all Apache sites with it went down, including gnu.org). 2) Ours is the only LE client built directly into the web server, so "reliability" isn't really a comparable factor. By doing renewals automatically, Caddy's HTTPS implementation is more reliable and robust than doing it manually.
      • stephenr 9y ago
        > 1) Ok fine, you want to pretend HAProxy isn't a thing that exists, we can do that. > 2) That isn't necessarily a good thing. Have you ever heard of separation of concerns? You specifically mentioned how Caddy can manage 2-3 week outages, as if it's something unique to your software. Every LE client that can be run from cron/a systemd timer renews certificates autagically. So where's the manual part that you keep claiming is not "robust"?
        • pfg 9y ago
          As someone who occasionally helps people with their web server/TLS/Let's Encrypt configuration, my experience is that there is a world of difference between a web server merely giving you the tools you'd need for a (relatively) sane OCSP and auto-renewal configuration, and one that takes care of everything. You should not need the amount of specialized knowledge you currently need to correctly configure OCSP on HAProxy or nginx, for example. Failure to renew a certificate (for any number of reasons) and missing intermediate certificates are the most common issues, and both of these are essentially solved with a web server that supports ACME natively. The same applies to OCSP stapling - we're not going to achieve ubiquitous stapling support on the server side if every server admin needs to deploy a bash script calling to openssl because the native OCSP implementation in their web server is broken.
          • stephenr 9y ago
            There is literally zero configuration required for HAProxy. You just store .ocsp files alongside the .pem's Yes you need to fetch them regularly. I use the aforementioned shell script to do this. Why do you people keep up this weird narrative that only caddy renews certificates automatically? The native ocsp handling in HAProxy isn't broken: it just expects to have TLS material provided to it. If someone setting up HAProxy on a server can't install a shell script calling two OpenSSL commands and setup cron to call it regularly, I don't think your big problem is "HAProxy doesn't handle ocsp". It's PEBKAC.
            • pfg 9y ago