By the way, Caddy CAN store certs in a database accessed by multiple servers. It coordinates cert management when configured as a cluster, automatically. Caddy is the only server that does this (for free).
Every single operational reason is a technical reason if it touches operation of the technology.
> By the way, Caddy CAN store certs in a database accessed by multiple servers. It coordinates cert management when configured as a cluster, automatically. Caddy is the only server that does this (for free
An edge web server should carry no knowledge of a concept of a cluster. It should simply be able to ask something for a cert. Otherwise it is a screw that insists that in order for it be used in high rise, it needs to be used in a specific pattern that the screw designer envisioned.
If you want to make Caddy easily adoptable in high rises I suggest the following path:
1. Subscribe to events saying "fetch this cert from here"
2. Emit events saying "Need to renew X" when you need to renew.
3. Create ability to forward renew requests to renew requests processor.
4. Make request processor update the cert store and emit the event that the key pair is available.
Caddy doesn't. That's what's so interesting!
> It should simply be able to ask something for a cert.
It does.
> I suggest the following path:
Oh good! That's pretty close to how it actually works already!
I'm happy to explain more how Caddy actually works before we start armchairing solutions here. Or, feel free to read the code for yourself: https://github.com/mholt/certmagic/
Once you can run multiple processes and have service discovery, the need for this stuff goes away. For example, I use cert-manager to get certificates for my Envoy edge proxy. cert-manager runs continuously and updates the TLS certificates in a Kubernetes secret. Kubernetes injects the secret into the Envoy container as files, and then Envoy reads them without any knowledge of where they come from or how they can be renewed. (It could also be configured to get them at runtime with xDS / Universal Data Plane API). This is all very easy and provides infinite interchangeability; there would be no change in cert provisioning necessary if I switched to Nginx or HAProxy.
But, most people don't have a setup that supports something like this, so they really need the all-in-one thing or they're just going to say "we don't really need TLS". They get by because nothing in their infrastructure ever changes; certs are new because they require operator intervention every 90 days and that is a new experience. It is unfortunate, but that's where most of the world is at right now.
However if an author of the solution does insist on implementing it in one binary with orchestration step being in the code rather than pulled out into the infrastructure management, the author should not be surprised that no one outside tiny single server operations would consider it to be a contender.
The next problem that people will run into is that because they can't reliably run multiple "things", they won't have a monitoring stack to tell them that certs aren't renewing. But, maybe nothing bad will happen and it won't be a problem. "Hope is not a strategy" if you're a Google SRE, but people do pretty OK with hope in the real world ;)
Sort of agreed with this.
Based on my experience, the reality is a bit more complicated. As soon as one is past the "this VM is a special pet and it is the only one I have" stage in my experience even smaller companies get dozens and soon hundreds of distinct HTTPs entry points:
* Main site/API ( code )
* Ops support
* bizops ( invoicing/quoting )
Which is where the issues of monitoring and observability come up.
I bet techcrunch has close to a hundred HTTP/HTTPS entry points and every time they evaluate a solution to replace their current entry point structure they ask if the new method would at least solve all of their existing problems. Ops people aren't gong to add another partial solution so the mix.
I wouldn't be so sure about that. It's certainly possible that's the case but equally I've personally seen new sites on Techcrunch's scale literally served from a couple of a couple of boxes running Wordpress (I kid you not!) which sits behind a few more boxes running pretty aggressive Varnish profiles and then that is sat behind Akamai's CDN. Most of the content on news sites is static and highly cache-able so there isn't always the need to go down the micro-services route.
For example, does it run RabbitMQ anywhere? Rabbitmq admin front-end is HTTP. Same goes for Kafka and other applications and we aren't even touching bizops.
My point isn't to say you're wrong, just that there will be as many exceptions to your point as there are occasions it's accurate.
Can you elaborate on this? I'm not sure I follow; there's nothing preventing people from using something like https://ohdear.app/ (or any other monitoring tool) with a self-contained solution like Caddy. In fact, I recommend that people do.
This isn't how I like it, but I totally see the use case. Caddy is a part of that use case and is probably the reason it exists. I think that's fine!
(Edit: ohdear is really neat though, I think people might want that no matter what. You have to serve your status page from somewhere, might as well get some cert checks thrown in for free!)
All we're saying with this project is, "There is a better way going forward, and we're solving that problem."
Here's a typical problem of a distributed entry point system - network partitioning.
* If your key/cert store relies on key servers being always accessible from everywhere, it simply won't work.
* If your solution is to bake a key into a file system, then it is no better than existing nginx implementation.
Basically, if you want your solution to be adopted, it needs to be significantly better than the entrenched ones.