Just food for thought: Do certbot/acme clients try to do too much ?
I understand the need for "all-in-one" solutions which fetch a certificate, install it, notify admistrators, and so on. These clients server really useful purposes. However ...
Is it possible they do too much ? If the functions of fetching, installation, and notifications were handled by separate scripts (certainly via cron or somesuch) it might be much simpler to craft solutions for special cases, such as those using multiple servers handling the same domain.
I know better minds than mine have crafted wonderful and elegant solutions to thorny problems, and that cerbot architects have opted for monolithic solutions, but if someone could enlighten me, or toss a brickbat or two, or something, I would appreciate it.
I must admit I'm prejudiced toward solutions which involve clearly defined incremental steps toward an ultimate goal. To that end, I have supplemented acme.sh with some scripts of my own and have not invoked some of the fancier options to acme.sh out of sheer stubbornness.
Oh, well. Flame on! I have asbestos underwear on!
I suppose, but, that single "Swiss Army Knife" approach has achieved a very high ROI, thus far.
It also seems rather pointless (to me) to break such a tool down and produce the individual parts as "add-ons" [that then can only be used with that one specific ACME client].
If those "add-ons" would be standardized interactions across all ACME clients [which would take even more work!].
Is it worth the effort? [IMHO, the juice may NOT be worth the squeeze]
How many people could that even benefit [other than you - lol]?
The users' required technical level would be much higher that of the largest target audience.
And anyone with such technical skill would likely be able to make their own tool(s) or make due with existing "all-purpose" tools.
I'd say that is where we need to look for the answer:
What has already been done along these lines (by any such techies)?
Where can one find any such "single-purpose" tools? [I'd start my search at GitHub]
Just my two (non-flammable) cents - LOL
Hi rg305 - I figured more folks would weigh in, but it appears the topic is of little interest to other than you and me. Thanks for your thoughts. Asbestos underwear itches, so I may go commando.
And ... thanks for all of your contributions to the LE community!
I think the most convenient case is that more programs which need certificates will integrate with ACME directly, like how Caddy and traefik webservers do. That has some of its own downsides, of course, particularily duplicating effort for DNS challenges, but makes HTTP/ALPN easy.
I think one of the big reasons that Let's Encrypt worked hard to ensure we have a standard API used by everyone is that we can have a rich ecosystem of clients, each of which takes on different tasks, depending on the needs of a user. Of course that leads to a new problem of how to figure out what client to use...
Without any redistribution system, this would imply more than needed load on the ACME server, right?
In an ideal world, a "big" user of certificates would have a single software system would be some kind of ACME "relay" ("primary") for the "secondary" software instances which acts like some kind of cache and perhaps safe redistribution of private keys et cetera.
Yeah, though software like cert-manager for example can share a cert among a kubernetes cluster, for example (though that example isn't great as cert-manager isn't quite as good at reusing certs as it could be). That kind of sharing with a cluster manager seems like a logical evolution of the single-server case, though as with all distributed computing, you now have a bunch of more things to think about.