3 ms·

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

> 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
    > 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. It does sound like there's some configuration involved after all, namely the configuration of a cronjob, and perhaps adjustments to a bash script. This is something that the majority of server operators will not bother with, though these numbers might look slightly better for HAProxy since that's generally something you see used by more experienced sysadmins. Even with nginx, we're talking about one line of configuration for the actual stapling file - that's not the blocker, it should just work, by default. Fun fact: IIS does this. > Why do you people keep up this weird narrative that only caddy renews certificates automatically? I'm not sure who "you people" are, and I never made any such claim. What I'm saying is that web servers that support ACME natively leave a lot less room for the types of misconfigurations that I commonly see. I'm aware of an ACME module for apache and lua scripts for nginx which provide similar features (regarding renewal and certificates, not for the OCSP aspect), but they're not part of what you run by default when you use those web servers. > The native ocsp handling in HAProxy isn't broken: it just expects to have TLS material provided to it. I have yet to see you explain why this should be necessary. The web server has all the information it needs to do this. Other web servers can do this. > 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. This is like arguing MongoDB should continue to bind to all interfaces by default because everyone should have firewalls in place. Yes, they should, but it's never going to happen, so why can't we just have a safe default?
    - stephenr 9y ago
      > It does sound like there's some configuration involved after all How is "schedule a script to run @daily" or whatever schedule you want, at all match up to what you suggested is required: >> You should not need the amount of specialized knowledge you currently need to correctly configure OCSP on HAProxy or nginx, for example. If you're configuring a public facing server, a cronjob should not be considered "specialised knowledge". > it should just work, by default 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 sure who "you people" are, and I never made any such claim. >> By doing renewals automatically, Caddy's HTTPS implementation is more reliable and robust than doing it manually. >> Failure to renew a certificate (for any number of reasons) and missing intermediate certificates are the most common issues, You're both giving the impression that Caddy is able to automatically renew certificates, while no other software does this. > I have yet to see you explain why this should be necessary. Off the top of my head: - Separation of concerns. I don't ask my mechanic to build me a car, or to drive me to the shops in it. - Not every organisation uses LetsEncrypt certificates. Some will even use self-signed certificates. - TCP or DNS load-balanced environments will want the exact same certificate & key on multiple servers. - 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? > The web server has all the information it needs to do this. 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. > This is like arguing MongoDB should continue to bind to all interfaces by default because everyone should have firewalls in place. No, it isn't. I'm sorry but you simply don't get the choice of arguing anything about how creating a fucking cronjob is "too hard" when Caddy doesn't even ship with a configuration to start as a service. "I know I just had to google the shit out of how to create a systemd unit, but fuck it, it's better than writing a damned cron job for oscp staples!"

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
  > 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. It does sound like there's some configuration involved after all, namely the configuration of a cronjob, and perhaps adjustments to a bash script. This is something that the majority of server operators will not bother with, though these numbers might look slightly better for HAProxy since that's generally something you see used by more experienced sysadmins. Even with nginx, we're talking about one line of configuration for the actual stapling file - that's not the blocker, it should just work, by default. Fun fact: IIS does this. > Why do you people keep up this weird narrative that only caddy renews certificates automatically? I'm not sure who "you people" are, and I never made any such claim. What I'm saying is that web servers that support ACME natively leave a lot less room for the types of misconfigurations that I commonly see. I'm aware of an ACME module for apache and lua scripts for nginx which provide similar features (regarding renewal and certificates, not for the OCSP aspect), but they're not part of what you run by default when you use those web servers. > The native ocsp handling in HAProxy isn't broken: it just expects to have TLS material provided to it. I have yet to see you explain why this should be necessary. The web server has all the information it needs to do this. Other web servers can do this. > 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. This is like arguing MongoDB should continue to bind to all interfaces by default because everyone should have firewalls in place. Yes, they should, but it's never going to happen, so why can't we just have a safe default?
  - stephenr 9y ago
    > It does sound like there's some configuration involved after all How is "schedule a script to run @daily" or whatever schedule you want, at all match up to what you suggested is required: >> You should not need the amount of specialized knowledge you currently need to correctly configure OCSP on HAProxy or nginx, for example. If you're configuring a public facing server, a cronjob should not be considered "specialised knowledge". > it should just work, by default 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 sure who "you people" are, and I never made any such claim. >> By doing renewals automatically, Caddy's HTTPS implementation is more reliable and robust than doing it manually. >> Failure to renew a certificate (for any number of reasons) and missing intermediate certificates are the most common issues, You're both giving the impression that Caddy is able to automatically renew certificates, while no other software does this. > I have yet to see you explain why this should be necessary. Off the top of my head: - Separation of concerns. I don't ask my mechanic to build me a car, or to drive me to the shops in it. - Not every organisation uses LetsEncrypt certificates. Some will even use self-signed certificates. - TCP or DNS load-balanced environments will want the exact same certificate & key on multiple servers. - 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? > The web server has all the information it needs to do this. 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. > This is like arguing MongoDB should continue to bind to all interfaces by default because everyone should have firewalls in place. No, it isn't. I'm sorry but you simply don't get the choice of arguing anything about how creating a fucking cronjob is "too hard" when Caddy doesn't even ship with a configuration to start as a service. "I know I just had to google the shit out of how to create a systemd unit, but fuck it, it's better than writing a damned cron job for oscp staples!"