Hacker News Reader

Comment by corrral | Hacker News Reader

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.

View on HN

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

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.

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)

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/2ceb535e076ed9b3083...

Let's Encrypt themselves has called Caddy the "gold standard" of certificate automation. (Not certbot.)

/me mumbles incoherently about Apache httpd

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.

funny enough, apache does have mod_md that will deal with LetsEncrypt

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.

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.

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

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

Here's the numbers I commonly cite: 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

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.

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 I took pains to say "community-maintained" because there's also an official nginx ingress controller from F5 (current corporate owner of nginx).

openresty and cloudflare are both nginx forks

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?

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/) 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.

Caddy provides higher memory safety guarantees than C servers.

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.

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.

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.

Guess which web servers use(d) openssl...

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.

I don't understand your response.

There's not a single proof except heartbleed in OpenSSL. I merely asked the author to provide the proof, not for you and I to engage in Go's memory safety and billions in damages and inherent nature of C and so on.

If we were to sum all the "damages" caused by faulty software, we'd arrive at a number that exceeds the total sum of money on planet Earth, let's not use that false metric for this discussion.

Is there an actual problem right now with nginx that Caddy circumvents with its architecture? Yes or no? That's the question.

Yes

Yes.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0133

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2028

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2089

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4315

Should I go on? None of the above errors is possible in a memory safe language like golang.

https://www.abetterinternet.org/docs/memory-safety/

Garbage-collected language seems to be slower.

Discord have switched away from Go for some performance-critical services because of it. [0] https://discord.com/blog/why-discord-is-switching-from-go-to...

The webserver will rarely be your bottleneck. Your application or database will be long before the webserver is.

I don't find it convincing to switch to a slower alternative.

What are your performance requirements?

Go is fast enough for Google. It's too slow for you?

Aren't proxy server more performance critical than usual backend code?

No. The proxy is almost never the bottleneck.

Reply on news.ycombinator.com