> If you're configuring a public facing server, a cronjob should not be considered "specialised knowledge".

Knowing how HAProxy's OCSP implementation works (i.e., by looking for a $cert.ocsp file) is the specialized knowledge. Odds are, you don't know about it and just won't use OCSP stapling. This is especially true since every web server does this differently.

> HAProxy and nginx do a fucking shit ton more than Caddy does. HAProxy doesn't really have a "default" you have to tell it what you want to do, specifically. This is a good thing.

I'm not arguing that it doesn't do a lot of things Caddy doesn't. I'm arguing for sane defaults. If I tell HAProxy to enable TLS and provide a certificate that contains an OCSP AIA extension, a sane default would be to use that information to manage OCSP stapling.

> You're both giving the impression that Caddy is able to automatically renew certificates, while no other software does this.

You're leaving out the part where I say these issues "[...] are essentially solved with a web server that supports ACME natively". I'm not referring to Caddy specifically. The web server doing this natively is far less error-prone. I have also mentioned alternatives.

> - Separation of concerns. I don't ask my mechanic to build me a car, or to drive me to the shops in it.

Where do you draw the line? Most deployments let their web servers handle TLS. OCSP stapling should be part of a modern TLS deployment. You could similarly argue that using HAProxy for TLS is wrong (and that you should rather put pound or stunnel in front of it).

> - Not every organisation uses LetsEncrypt certificates. Some will even use self-signed certificates.

That's fine; you can continue to manually configure certificates, even with Caddy, and I'm definitely not arguing that this option should be removed. ACME is also an open standard, so switching to other CAs can be as simple as configuring a different ACME server url.

> - TCP or DNS load-balanced environments will want the exact same certificate & key on multiple servers.

That's why you can replace the certificate and key storage in more complex environments[1].

> - Caddy has already shown that trusting some "automagic" solution can bite you in the ass. Remember that time Caddy wouldn't even start, even though it had perfectly valid certificate material in it's cache, because LE was down?

Software can break, what a surprise. You could similarly have a broken OCSP updater script that puts empty or expired OCSP responses in your stapling file because the check is missing or incomplete and break the site for your visitors. Or your ACME client could fail on renewal because of a backend change on Let's Encrypt's end that exposes a bug in it[2].

> HAProxy doesn't know the email address I'd want LetsEncrypt to use for notifications. It also shouldn't be agreeing to LE's terms on my behalf.

You can ... provide your email address? You keep arguing that this stuff is easy, surely adding a single line with your email address won't break the camel's back. Accepting the TOS can be solved as part of the installation or configuration process, much like ACME clients do it.

Anyway, you seem to be having some kind of problem with Caddy. I'm not interested in that discussion (which is to say I'm not interested in discussing this further, I think I've made my point) - my goal is to improve the user experience of server admins when they enable HTTPS, and I have no doubt that native ACME support and automated OCSP management, both with sane defaults, would both help HTTPS adoption and improve the quality of the TLS configuration of your average web server.

[1]: https://godoc.org/github.com/mholt/caddy/caddytls#Storage

[2]: https://community.letsencrypt.org/t/acme-sh-standalone-fails...