Hi All
I have been thinking about how to run certbot in ways other than the CLI.
I have used http://www.hug.rest/ for a few projects and think it can be used to add a API web interface to certbot without much rework.
Is there any interest in this. If so I can put together some prototype code
Andrei
I’m confused. The ACME protocol is already REST based. And certbot is one of many REST clients consuming that API. So you want to build another REST API the utilizes certbot under the hood? So you’d then have REST clients calling your REST API which calls certbot (a REST client) which calls the ACME REST API?
The one reason it could be attractive is that there have been a few posts from integrators who have been driving Certbot programmatically.
You could argue that it’s the wrong thing to do, but it’s happening nonetheless.
Saves them having to implement persistence, renewal, account management behavior, templating their webserver config, etc I guess.
Maintaining a third-party public API for Certbot could be tricky over time, though.
Wow!
I applaud the effort, but it better come with very explicitly detailed error messages…
[or this may just make things that much harder to troubleshoot when things don’t work as expected]
this is true however there are client side functions such as management of account keys, generation of CSRs and install behaviours which the ACME APIs won’t do for you.
key consideration is that the core certbot libraries are fairly well written and maintained
Currently the only option is to access them is via a CLI
Hug.rest has the advantage of being able to quickly wrap any functionality without having to write a web server.
That was generally my thinking
instead of typie certbot --renew xxx
you could hit and API endpoint /renew
idea would be to wrap certbot messages in the response so that people don’t need to learn new troubleshooting
I feel like I must be missing something obvious here. Is the target audience for this a typical user who would be installing it on their server in addition to certbot in order to call certbot remotely via REST? And if so, isn’t that more complicated than just calling the CLI once and letting cron auto-renew?
Or is this to setup like a REST based version of (for example) SSLForFree where users can’t/won’t run a normal ACME client on their own machine?
The other thought that occurs to me is that Certbot uses a lockfile very aggressively, so access to the web API would have to be completely serialized (arguably rendering it useless).
good point - enough theory — testing time
will upload sample 
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.