In Caddy 2.3, Caddy [1] will default to both Let's Encrypt and ZeroSSL [2]. If it can't get a cert from one, it will try the other. You can configure more too, including self-signed certs, as a last fallback for example. Caddy will be the first web server and ACME client to support multi-issuer fallback. (Pre-releases coming soon, or you can build from source and try it today.)
ZeroSSL's website is being updated to clarify that certs are free and unlimited through ACME. You can even view them in your ZeroSSL dashboard.
I've been using Caddy on some personal and community sites for around a year and it's worked out just great! The built in certificate management has been so nice compared to having to manage external letsencrypt tooling.
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.
Yeah, I feel that. I want to work on docs and knowledge-transfer a lot more in 2021. 2019 and 2020 were definitely full of sprinting to bring Caddy 2 up to par. I think in terms of major functionality it's settling down now, so docs and guides will be more feasible.
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...
Agreed, I almost mentioned documentation but I forgot... My use-cases are ridiculously simple, and it's definitely gotten way better in the last year, but just figuring out the syntax for putting my e-mail address in the config file and how to start the server without it asking me questions on stdin required some trial and error. Nothing major, but there just wasn't much on Google at the time.
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.
Yes Caddy is fantastic. My favorite unexpected use case has been testing Apple webhooks and sign in, which requires TLS even for local development. Caddy made this so easy! I just set up DNS for my home address, configured my firewall to serve on public port 443 and fired up Caddy. Would have been endlessly more annoying to configure TLS for local development before Caddy. The config file for this is literally 3 lines:
How about supporting absolute hostnames? Even this site (https://news.ycombinator.com./) supports them just fine, only Caddy doesn’t. Caddy does it so badly that the HSTS preload for caddyserver.com is interpreted by browsers as applying to caddyserver.com. (which is correct), but caddy won't actually serve that spec-compliant website: https://caddyserver.com./ (just throws an SSL error)
The specification explicitly says what you want is the Wrong Thing™. The designers of SNI didn't leave this vague, they spelled it out first in RFC 3546 and most recently in RFC 6066
> "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.
It's not just SNI that's the issue. Caddy also can't handle Host headers with trailing dots, where the spec explicitly states those should be handled.
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)
Honestly, in the 5+ years of Caddy, you're the only person I've ever seen complain about this. And you're relentless about it. You bring it up on every thread on HN that ever has a mention of Caddy. It's very annoying.
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.
This has been a shitty thread to read, tbh. It's clearly not pointless if there are improvements which could be made to make the product more spec-compliant, such as handling terminating dots in Host headers. And I'm saying this as someone who's never used Caddy for anything, ever.
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.
Is it "trolling" if one expects a webserver to work like every other webserver, even offering to make the required changes?
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:
Yes, because Caddy is not like every other webserver. It also automates TLS management, can act as an ACME server, etc.
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.
> Yes, because Caddy is not like every other webserver. It also automates TLS management, can act as an ACME server, etc.
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.
> even using the same libraries for most of the functionality
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.
I’m not using caddy – but I get complaints that websites hosted on caddy servers don’t work with my tools, which follow the specs and require the absolute URL to work just as well as the relative one.
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
Hello, ironically it was me who has created that issue some years ago. I saw that http://ai./ works in a browser and wondered why chagemann.de. doesn't. The culprit was caddy, and the caddy maintainer didn't want to fix it (or apparently accept PRs fixing it). Not sure where the trolling is supposed to be at.
Thank you so much for Caddy and open sourcing it completely. Every few years there comes a piece of software that really opens ones eyes how overcomplicated life was before. Caddy is absolutely one of those.
True, that's one reason, but I've been planning this feature for years and would have implemented it either way. As explained in the linked pull request:
- 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.
There's also a lot of opportunity for CAs to get better IMO, so competition is useful. I'd hate to see a commercial company displace LE, but there are so many value adds that can be sold once you're the CA of choice that it seems inevitable that a commercial CA with a LE style free tier is going to have a lot of opportunity.
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.
ACME has a concept of EAB (external account binding) credentials, basically like an API key. https://zerossl.com/documentation/acme/
Caddy supports this, so what you want to do should be covered.
> 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.
At ZudVPN (https://zudvpn.com) we use Caddy to retrieve certificates for subdomain.zudvpn.com where they are later used for VPN connections instead of web server. This makes us be able to issue personal VPNs secured with SSL/TLS on any major Cloud Providers. I would thank both Caddy and Let's Encrypt that opens endless opportunities around secure connection.
In Caddy 2.3, Caddy [1] will default to both Let's Encrypt and ZeroSSL [2]. If it can't get a cert from one, it will try the other. You can configure more too, including self-signed certs, as a last fallback for example. Caddy will be the first web server and ACME client to support multi-issuer fallback. (Pre-releases coming soon, or you can build from source and try it today.)
ZeroSSL's website is being updated to clarify that certs are free and unlimited through ACME. You can even view them in your ZeroSSL dashboard.
[1]: https://caddyserver.com
[2]: https://github.com/caddyserver/caddy/pull/3862