6 ms·

It's much more widely used and has been around a whole lot longer, both of which confer many benefits. Personally, if nginx made letsencrypt as easy as caddy d

It's much more widely used and has been around a whole lot longer, both of which confer many benefits. Personally, if nginx made letsencrypt as easy as caddy does, I'd never even think about caddy. That's its One Thing that kinda tempts me.

ancientsofmumu 4y ago
> if nginx made letsencrypt as easy as caddy does The EFF cerbot plugin has it covered; assuming your generic Debian server with nginx already configured to host www.domain.com (trivial hello, world setup - nothing fancy) then it's: apt-get install cerbot python3-certbot-nginx certbot --nginx -d www.domain.com -d domain.com \ --agree-tos -m "email@domain.com" --no-eff-email \ --deploy-hook "systemctl reload nginx" systemctl restart nginx All done. Certbot is already running as a systemd service to handle ongoing renewals and it'll now restart nginx if your cert is updated. This example uses the trivial http-01 ACME method, if you need the more complex DNS based setup for wildcards that'll take a bit more elbow grease.
- francislavoie 4y ago
  FWIW, having the ACME client separate from the server has a bunch of downsides. It's less robust, can't provide OCSP stapling and automatic renewal on revocation, doesn't have issuer fallback, can't offer you On-Demand TLS, etc.
  - pilif 4y ago
    I agree with most points, but OCSP stapling is independent of ACME and thus is perfectly doable with nginx and an externally obtained let’s encrypt certificate. That aside, for me the trade-off was different and I was willing to give up the benefits of included acme support for the benefits of running a very well-supported and well-known web server that at this point hosts most of the internet and which can run on port 80/443 without iptables hacks (not sure whether this still applies to caddy)
    - francislavoie 4y ago
      What I meant was using OCSP status (from stapling) to trigger reissuance on revocation. I don't think this can be done with nginx and certbot unless nginx makes its OCSP status available for the certbot client to read from, or having an event trigger in nginx somehow to get certbot to run. Either way, it's extra faff that you don't need to worry about with Caddy. > which can run on port 80/443 without iptables hacks Not sure what you mean. Do you mean that you need root to bind to those ports? In which case, you can give the process CAP_NET_BIND_SERVICE which lets it. Caddy's systemd service does this, and runs as a non-root user: https://github.com/caddyserver/dist/blob/2ceb535e076ed9b3083e74475f142437f4284e67/init/caddy.service#L33 https://github.com/caddyserver/dist/blob/2ceb535e076ed9b3083...
- mholt 4y ago
  Let's Encrypt themselves has called Caddy the "gold standard" of certificate automation. (Not certbot.)
the_third_wave 4y ago
I never experienced nginx' way of handling certificates as difficult and I prefer to keep my web server independent from the certificate management system since I use those certificates for more purposes than just web servers so I have not looked into the supposedly superior way caddy handles this workflow. I handle certificate requests and updates on a separate system which then distributes certificates and handles daemon restarts to where and when these are needed by using certbot hooks. All it takes to request and distribute a new certificate is a single command on that certificate management system, the rest follows automagically. Am I missing something by doing things this way?
dekobon 4y ago
Disclaimer: I am one of the authors of the project. I do wish that NGINX made LetsEncrypt as easy as to use as Caddy does. We are all big fans of LetsEncrypt and are quite happy to see NGINX donating to the project. In this project (MARA), LetsEncrypt support is integrated via [Cert Manager](https://cert-manager.io/ https://cert-manager.io/) for Kubernetes. This is nice because it supports certs from a variety of issuers like AWS, Google, Vault, Cloudflare, etc in addition to Let's Encrypt.
boardwaalk 4y ago
For concrete comparison, nginx backs something like 40% of the top 10k websites. Caddy is a fraction of a percent.
- mooreds 4y ago
  Here's the numbers I commonly cite: https://news.netcraft.com/archives/2022/04/27/april-2022-web-server-survey.html https://news.netcraft.com/archives/2022/04/27/april-2022-web... 31% nginx 23% apache 8% Openresty (which I've never heard of, looks like it is an augmented nginx) 5% cloudflare
  - favorited 4y ago
    Openresty is basically Nginx + Lua. I did some POCs on it back in the day, honestly surprised it's still around. It wasn't bad, just seemed like a product with a very small niche.
    - mwcampbell 4y ago
      If I'm not mistaken, the biggest user of openresty is the Kubernetes community-maintained nginx ingress controller [1]. [1]: https://github.com/kubernetes/ingress-nginx https://github.com/kubernetes/ingress-nginx I took pains to say "community-maintained" because there's also an official nginx ingress controller from F5 (current corporate owner of nginx).
  - phillipseamore 4y ago
    openresty and cloudflare are both nginx forks
mholt 4y ago
Caddy provides higher memory safety guarantees than C servers.
- zmxz 4y ago
  Source? Any content on memory safety concerns in "C" servers or problems that lead to catastrophic results in production? I'm interested in reading about it.
  - xyzzyz 4y ago
    Uh, google “heartbleed bug”, that’s just one example of a massive and catastrophic result of lack of memory safety in C. It probably costed something on the order of $1B for remediation efforts globally.
    - zmxz 4y ago
      Heartbleed was in openssl. I didn't ask about memory safety in C. Caddy author was pretty accurate with his statement, I asked for proof. Heartbleed is not the only memory leak, there's plenty, C's been around like software written in it. I'm aware of shortcomings.
      - mholt 4y ago
        Guess which web servers use(d) openssl...
      - xyzzyz 4y ago
        Sorry, I don’t get understand your response. Most Caddy’s competitors use OpenSSL, and so are vulnerable to bugs in it. A lot of those bugs, like for example heartbleed, are only possible due to the nature of the C language. Those kinds of bugs, the memory safety bugs, are prevented when using memory safe languages like Go. These bugs are real and serious, and collectively cost billions of dollars in damages.
        4y ago
hn_version_0023 4y ago
/me mumbles incoherently about Apache httpd
- aaaaaaaaata 4y ago
  Just when I think "It's gotta be secure by now, they must have figured it out" there's a new and disturbing Apache CVE — change my view.
- Spivak 4y ago
  httpd has the advantage that it has literally every feature you could imagine and a million more you couldn't but it's a slog to actually use.
  - anotherevan 4y ago
    > it's a slog to actually use. I don't know. I haven't used Apache HTTP in a while, but Nginx seems to have a lot more foot-guns. I'm planning on giving Caddy a go on my next server upgrade.
- corrral 4y ago
  Hahaha, I'm a dinosaur, too. I only started considering nginx something other than "that new-fangled crap" a few years ago. Caddy may get there in about a decade.
- attentive 4y ago
  funny enough, apache does have mod_md that will deal with LetsEncrypt

ancientsofmumu 4y ago

> if nginx made letsencrypt as easy as caddy does The EFF cerbot plugin has it covered; assuming your generic Debian server with nginx already configured to host www.domain.com (trivial hello, world setup - nothing fancy) then it's: apt-get install cerbot python3-certbot-nginx certbot --nginx -d www.domain.com -d domain.com \ --agree-tos -m "email@domain.com" --no-eff-email \ --deploy-hook "systemctl reload nginx" systemctl restart nginx All done. Certbot is already running as a systemd service to handle ongoing renewals and it'll now restart nginx if your cert is updated. This example uses the trivial http-01 ACME method, if you need the more complex DNS based setup for wildcards that'll take a bit more elbow grease.

francislavoie 4y ago
FWIW, having the ACME client separate from the server has a bunch of downsides. It's less robust, can't provide OCSP stapling and automatic renewal on revocation, doesn't have issuer fallback, can't offer you On-Demand TLS, etc.
- pilif 4y ago
  I agree with most points, but OCSP stapling is independent of ACME and thus is perfectly doable with nginx and an externally obtained let’s encrypt certificate. That aside, for me the trade-off was different and I was willing to give up the benefits of included acme support for the benefits of running a very well-supported and well-known web server that at this point hosts most of the internet and which can run on port 80/443 without iptables hacks (not sure whether this still applies to caddy)
  - francislavoie 4y ago
    What I meant was using OCSP status (from stapling) to trigger reissuance on revocation. I don't think this can be done with nginx and certbot unless nginx makes its OCSP status available for the certbot client to read from, or having an event trigger in nginx somehow to get certbot to run. Either way, it's extra faff that you don't need to worry about with Caddy. > which can run on port 80/443 without iptables hacks Not sure what you mean. Do you mean that you need root to bind to those ports? In which case, you can give the process CAP_NET_BIND_SERVICE which lets it. Caddy's systemd service does this, and runs as a non-root user: https://github.com/caddyserver/dist/blob/2ceb535e076ed9b3083e74475f142437f4284e67/init/caddy.service#L33 https://github.com/caddyserver/dist/blob/2ceb535e076ed9b3083...
mholt 4y ago
Let's Encrypt themselves has called Caddy the "gold standard" of certificate automation. (Not certbot.)

the_third_wave 4y ago

I never experienced nginx' way of handling certificates as difficult and I prefer to keep my web server independent from the certificate management system since I use those certificates for more purposes than just web servers so I have not looked into the supposedly superior way caddy handles this workflow. I handle certificate requests and updates on a separate system which then distributes certificates and handles daemon restarts to where and when these are needed by using certbot hooks. All it takes to request and distribute a new certificate is a single command on that certificate management system, the rest follows automagically. Am I missing something by doing things this way?

dekobon 4y ago

Disclaimer: I am one of the authors of the project. I do wish that NGINX made LetsEncrypt as easy as to use as Caddy does. We are all big fans of LetsEncrypt and are quite happy to see NGINX donating to the project. In this project (MARA), LetsEncrypt support is integrated via [Cert Manager](https://cert-manager.io/ https://cert-manager.io/) for Kubernetes. This is nice because it supports certs from a variety of issuers like AWS, Google, Vault, Cloudflare, etc in addition to Let's Encrypt.

boardwaalk 4y ago

For concrete comparison, nginx backs something like 40% of the top 10k websites. Caddy is a fraction of a percent.

mooreds 4y ago
Here's the numbers I commonly cite: https://news.netcraft.com/archives/2022/04/27/april-2022-web-server-survey.html https://news.netcraft.com/archives/2022/04/27/april-2022-web... 31% nginx 23% apache 8% Openresty (which I've never heard of, looks like it is an augmented nginx) 5% cloudflare
- favorited 4y ago
  Openresty is basically Nginx + Lua. I did some POCs on it back in the day, honestly surprised it's still around. It wasn't bad, just seemed like a product with a very small niche.
  - mwcampbell 4y ago
    If I'm not mistaken, the biggest user of openresty is the Kubernetes community-maintained nginx ingress controller [1]. [1]: https://github.com/kubernetes/ingress-nginx https://github.com/kubernetes/ingress-nginx I took pains to say "community-maintained" because there's also an official nginx ingress controller from F5 (current corporate owner of nginx).
- phillipseamore 4y ago
  openresty and cloudflare are both nginx forks

mholt 4y ago

Caddy provides higher memory safety guarantees than C servers.

zmxz 4y ago
Source? Any content on memory safety concerns in "C" servers or problems that lead to catastrophic results in production? I'm interested in reading about it.
- xyzzyz 4y ago
  Uh, google “heartbleed bug”, that’s just one example of a massive and catastrophic result of lack of memory safety in C. It probably costed something on the order of $1B for remediation efforts globally.
  - zmxz 4y ago
    Heartbleed was in openssl. I didn't ask about memory safety in C. Caddy author was pretty accurate with his statement, I asked for proof. Heartbleed is not the only memory leak, there's plenty, C's been around like software written in it. I'm aware of shortcomings.
    - mholt 4y ago
      Guess which web servers use(d) openssl...
    - xyzzyz 4y ago
      Sorry, I don’t get understand your response. Most Caddy’s competitors use OpenSSL, and so are vulnerable to bugs in it. A lot of those bugs, like for example heartbleed, are only possible due to the nature of the C language. Those kinds of bugs, the memory safety bugs, are prevented when using memory safe languages like Go. These bugs are real and serious, and collectively cost billions of dollars in damages.
      - 4y ago

hn_version_0023 4y ago

/me mumbles incoherently about Apache httpd

aaaaaaaaata 4y ago
Just when I think "It's gotta be secure by now, they must have figured it out" there's a new and disturbing Apache CVE — change my view.
Spivak 4y ago
httpd has the advantage that it has literally every feature you could imagine and a million more you couldn't but it's a slog to actually use.
- anotherevan 4y ago
  > it's a slog to actually use. I don't know. I haven't used Apache HTTP in a while, but Nginx seems to have a lot more foot-guns. I'm planning on giving Caddy a go on my next server upgrade.
corrral 4y ago
Hahaha, I'm a dinosaur, too. I only started considering nginx something other than "that new-fangled crap" a few years ago. Caddy may get there in about a decade.
attentive 4y ago
funny enough, apache does have mod_md that will deal with LetsEncrypt