Regular reminder that the best ACME clients will fall back to other CAs if one is down. For example caddy does this. (Disclosure yada yada)
Just make the disclosure clear but short if the comment is a throwaway, or don't mention your own service, otherwise it's a race to the bottom.
I recommend trusting multiple CAs (but not too many): https://matt.life/writing/the-acme-protocol-in-practice-and-...
> (I don't know if it is, but I would think it's a layering violation for an HTTP server to also be a DNS server.)
Caddy 2 is, at its core, a server of servers. The HTTP server is just an "app module" for Caddy. There are other servers; I don't know of a DNS server app yet. (CoreDNS is a fork of Caddy v1, though.)
Are there others that do it, or are you just saying that yours is the best?
While we're on the topic, I will say that Caddy has independently and repeatedly been cited as the gold standard of ACME clients, "the best client experience," and "we hope to see other servers follow Caddy's lead." [0] [1] [and others I don't have links to currently].
Sorry that I happen to be the author. It's really not about that though -- it just matters that an ACME-native HTTPS server exists. We need more integrated fully-native ACME clients.
> actually curious whether any other ACME clients are implementing that fallback.
There are at least one or two others. I don't recall which ones at the moment but I think Certify the Web may be one. Edit: mod_md is another apparently!
Most of the "popular" software in this space is garbage. I spent the entire day today (aside from meetings and helping other people debug problems) wrestling with the fact Apache seems to be designed so heavily with a C programmer mindset that even the idea of reporting problems has never occurred to them. Just blunder on, it'll be fine, don't think about it. You can sprinkle complete nonsense into Apache configuration files and, until you trip an actual syntactical error and blow up their parser, Apache just presses on anyway with the nonsense values you provided, and if that doesn't work, no reason to report it just do whatever was the default and hope that's OK.
As far as I can tell, in the wild the result is a lot of Apache configuration is complete nonsense, but hey no errors are reported, so, copy, paste, move on.
Remember, this was six years ago. That's an eternity in this industry. Caddy is a very different project than it was then, and Matt has a different and more stable revenue stream than he did then. We can promise we'll never attempt the same thing again.
But seriously, this comes up in like one in ten HN threads where Matt comments, it's exhausting to keep telling people "okay can you please forget what you remember from 6 years ago and look at the project for what it is now?"
> Remember, this was six years ago. That's an eternity in this industry. Caddy is a very different project than it was then, and Matt has a different and more stable revenue stream than he did then. We can promise we'll never attempt the same thing again.
I think this was meant to be reassuring, but it really makes it sounds more like it was purely a pragmatic thing. Okay, so now Caddy has stable cash flow, so no adware. Next year the economy lurches and the money goes away; is caddy going to start making awkward decisions again?
> But seriously, this comes up in like one in ten HN threads where Matt comments, it's exhausting to keep telling people "okay can you please forget what you remember from 6 years ago and look at the project for what it is now?"
You know that line about how people will forget what you do, but not how you made them feel? I remember exactly how I felt when the wonderful server software I was using decided to start shipping adware. And now, having backed off but never actually apologized, you want people to just forget about the whole thing? That's not how it works. Edit: Now that we've had this exchange, and at least you have called it a mistake and said it won't happen again, I can update my evaluation based on that. I would suggest that saying that six years ago in the announcements channel would have reduced the number of times you needed to have this conversation.
Edit2: Realized there was a much more succinct way of answering: If someone feels that you wronged them, you don't get to choose when they get over it. A lot of users felt that caddy treated them poorly. And honestly, even if the project had said then what you're saying now, some of them would still remember that.
This incident wasn't just about downtime, it was also about issuing non-functional/non-compliant certificates.
Caddy staples Valid OCSP responses to all certificates that have an OCSP responder, so if browsers aren't accepting that, then arguably the clients are broken, because that response is valid until a few days from now. But before the 100% valid and trusted OCSP staple expires, Caddy will get a new staple that presumably says Revoked, and replace them right away before browsers would ever see a Revoked status.
(Revocation is broken ;P)
I wonder if we should be doing some basic sanity checks on newly obtained certificates in Caddy, and treat this as a failure, and try the next configured CA instead.
(Obviously SCT signatures will require some external resource so we would have to weigh that a bit more, maybe make it configurable...)
Issue opened here to discuss, though it does sound troublesome/tedious: https://github.com/caddyserver/certmagic/issues/240
You can trust the ACME CAs listed on this site: https://www.acmeisuptime.com/ (Although, I think that list could use some updating. I'll ping the author.)
Personally I would use Let's Encrypt, ZeroSSL (Sectigo) and Google Trust Services. There are, of course, others. But which ones you choose depend on your requirements and such. (Some offer business support, for example.) SSL.com and Sectigo also offer ACME but I am not sure how performant their CA software is.