Building a Let's Encrypt module

Erica Portnoy erica at eff.org
Sat Feb 15 00:44:16 UTC 2020


Hello nginx-devel.

I'm a developer on Certbot, EFF's Let's Encrypt client. I've been
working on Certbot's NGINX plugin for a few years now. This is an
extension of the standalone Certbot program that operates on a user's
behalf to modify their configuration files to retrieve and install SSL
certificates.

For the obvious reasons, this approach has its drawbacks. For a while
now, the Certbot team has been dreaming of a way to get certs
automatically as part of the server, without a standalone application
needed (similar to what Caddy does).

From our research, it seems like the best approach would be to write an
NGINX module. I've found some information about what this would entail
and the best ways to go about doing so, but I still have some open
questions. This is where you all come in. I would love any thoughts,
feedback, proposed solutions, clarifications, pointing out of
fundamental errors in understanding for the following:

Basically our thinking so far is to write a plugin that will fetch and
load certificates behind the scenes. Ideally it would do this decoupled
from incoming requests. The problem we've been running into is about
permissions and available actions -- we haven't found a clean way to
either run scheduled tasks (can't modify cron from inside a module) or
reload NGINX configurations from inside a plugin in vanilla open source
NGINX. Are there ways to do this that we just haven't found? And if not,
is there any chance of getting someone from the NGINX team to work with
us to make that possible?

If those are possible, we'd also have to decide if it's best to include
an ACME library within the plugin itself, or shell out to certbot to
fetch and/or manage certificates. Is calling out to an external process
from inside an NGINX plugin possible?

If we do get all of this working, we'd want to have the easiest possible
solution for users to install the plugin. Obviously the easiest way
would be for it to be built into NGINX itself :) Barring that, we could
probably find some way to package and distribute it. We're currently in
the process of moving our distribution to Snaps, so once we get that
infrastructure set up there'll be the option of repackaging NGINX with
the plugin included and distributing the whole thing.

The other thing we were considering was to build on top of OpenResty
instead, which seems to have a bit more functionality available.
Obviously that isn't ideal, but if it's the only way forward we might
start looking into performance and distribution options for that.

Looking forward to hearing thoughts.

Best,

Erica Portnoy
Senior Staff Technologist
Electronic Frontier Foundation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20200214/6376a218/attachment.htm>


More information about the nginx-devel mailing list