More recently I set up a VM at work to be a domain redirector for a bunch of typo domains to our main domains, since the old outsourced redirectors didn't have TLS, and it was dead simple!

I would appreciate better and consistent documentation to do more non-trivial things with Caddy, but for your basic use-cases it takes a lot of the pain away. Unfortunately, nginx and Apache still win on the (probably unfair) basis that they've got well over 10 years of history, and all of the cultural knowledge that comes with that.

In the meantime, I always encourage anyone to contribute to our wiki: https://caddy.community/c/wiki/13 -- there's already lots of great topics there and room for plenty more, especially examples.

Hint: there's a LOT of market space for paid content to master the Caddy web server, if anyone reading this is looking to profit from their expertise...

Docs have gotten way better since. As has the install story. Before it was some scripted thing that I was never quite confident in, now it's a deb package that I feel confident in running updates and Ansible against. And honestly I have not had any problems since installing it.

my.public.hostname {

   reverse_proxy localhost:3000

}

https://tools.ietf.org/html/rfc6066#section-3

> "HostName" contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using ASCII encoding without a trailing dot. †

So, when your web browser sends the hostname "news.ycombinator.com." that's not an "absolute hostname" that's just an error. Maybe you can demand that web browsers stop doing that, but they'll likely tell you they don't care, and you should stop writing URLs incorrectly.

† The trailing dot rule was in every version, but earliest sources talked about using UTF8 because they pre-date the insight that all this backend (ie not human-facing) stuff can use A-labels which are ASCII and avoid any complicated Unicode problems. This version just says to use ASCII here.

So while the SNI error is clearly on browsers (and bugs have been already filed), the Host header issue is clearly on caddy (which caddy sees as wontfix)

That said, you can just make a site block with that host label and Caddy will handle it just fine. You just need to explicitly ask Caddy for it.

    example.com, example.com. {
        ...
    }

That's what mholt said as well: It's the site maintainers task to fix it. Yet caddyserver.com still doesn’t support it.

> you're the only person I've ever seen complain about this

I didn’t actually find the bug myself, someone else did first, but it’s something that’s been annoying me for quite a bit.

> You bring it up on every thread on HN that ever has a mention of Caddy. It's very annoying.

It’s definitely a red flag something people should know before using caddy, as it’s a sign caddy will also interpret other specs funnily.

Right, because Matt (and the large majority of everyone on the internet) doesn't care.

> It’s definitely a red flag something people should know before using caddy, as it’s a sign caddy will also interpret other specs funnily.

Pure FUD. It's such a non-issue. As you've been told many times.

If it's such a non-issue, why did matt say he wouldn't accept a PR that'd fix this?

This is all from four years ago. And kuschku hasn't taken no for an answer after all this time. It's frustrating and annoying to hear their complaints on every HN thread since.

I agree with you the thread is shitty. I'm just hoping being direct will end the trolling.

If you want to learn why supporting FQDNs is important, you can actually read the issue and PR on the traefik repo where they chose to add support for this:

https://github.com/traefik/traefik/issues/4622 https://github.com/traefik/traefik/pull/4763

They just accepted the issue, and fixed it. Super easy, no 4 years of "no one needs this" "no you're wrong" "the specs are wrong" "you're trolling"

You make it out to be a simple change, but it's really not. And the arguments for making any changes are not compelling enough to warrant the risks involved. Compliance for the sake of compliance is completely pointless.

That’s why I’m comparing it to traefik, which can also automate TLS management, in the exact same way (even using the same libraries for most of the functionality, they’re after all both go webservers).

> And the arguments for making any changes are not compelling enough to warrant the risks involved

Why is it that you think you know better than the maintainers of e.g. traefik? It’s not like this is legacy functionality they kept around just for the sake of it, they added it in 2019 because there’s demand for it, today.

You're wrong. Caddy uses a superior library that's been more stress-tested at scale in production: https://github.com/caddyserver/certmagic and https://github.com/mholt/acmez - neither of which lego uses. Bugs and limitations in lego caused severe problems for several of our larger customers.

Actually no, not anymore.

https://github.com/caddyserver/caddy/pull/3621

> because there’s demand for it, today

We've only seen the demand from you. Nobody else. One individual isn't enough demand.

At this point it's just a game of wasting other people's time.

And I can’t remotely telepathically make all caddy users switch to nginx. So as long as a single HTTP server runs a version of caddy with this bug, I’ve got extra work to do, because the caddy people are wasting my time

"Caddy has been acquired by the company behind ZeroSSL"

- Let's Encrypt is a busy non-profit organization. We can help maximize their budget by not using it as the exclusive default for every server.

- ZeroSSL does not have rate limits and is also publicly trusted. And yes, it is free to use it with ACME.

- ZeroSSL offers a graphical dashboard where you can log in and see and download your certificates.

- Having more than just 1 free ACME CA is a very, very good thing for the PKI ecosystem.

This is the beauty of standardization; if you give a server a URL, you can give it two and three and four, and not have to worry about global reliance on a single source.

IMO the biggest, easiest feature no CA has implemented is CTLog monitoring / reconciliation. The problem I have with LE even on a small scale is that I'm grabbing certificates for ~20 (sub)domains. I also have several of them set up via Cloudflare. With CTLog monitoring notifications (via Cloudflare and Facebook), I get too many notifications. I don't know what's coming or going or which machines are requesting certificates for which (sub)domains.

A service like ZeroSSL is already acting like a central point of certificate management (for me), so it's the ideal location to do CTLog monitoring since the bulk of certificate issuances happen there. That means legitimate CTLog entries can be reconciled and ignored silently (they'll already show up in the dashboard).

I'm not sure how user accounts work in ACME, but the other thing I'd like is to be able to track which user or machine requested a certificate.

I'm sure something like that could also be built as a proxy. I thought about trying once, but it's firmly in my "things I'll never get to" idea box. Lol.

Another problem I've had with LE that could use a solution is a 3rd party service that I signed up for requesting certificates, but not installing them correctly and hitting the LE limits for that domain. If the mindshare changes from LE to ACME, maybe there'll be a day where 3rd parties will let me specify an ACME provider and link it to my main account somehow.

Hey, where on the site is that said?

I'd like to consider that for work purposes, but I can't find the "we don't rate limit" writing anywhere.

> Unlimited & Zero Cost

> In an effort to ensure the widest possible SSL certificate coverage around the world, our team has decided to keep all ZeroSSL certificates created using the ACME protocol completely free of charge.