Pure Lua ACME protocol implementation

[GUI]

I'm opening this issue to track the idea of a pure Lua ACME client implementation (instead of relying on dehydrated). I'm not sure if/when this will happen, but I thought it was worth having an issue to reference and be able to discuss.

This idea has been rolling around since the initial creation of lua-resty-auto-ssl, as the TODO section of the README has noted since the beginning:

We currently rely on dehydrated as our Let's Encrypt client. It's called in a non-blocking fashion via lua-resty-shell and sockproc, however it might be simpler to eventually replace this approach with a native OpenResty Let's Encrypt client someday.

For the most part, using dehydrated has served us well, and has allowed us to offload all the underlying ACME protocol work for registering certs with Let's Encrypt. That being said, the reliance on lua-resty-shell and sockproc also adds complexity to lua-resty-auto-ssl for a few reasons:

• It requires the extra local HTTP server running on port 8999 used for communication between dehydrated's shell scripts and lua-resty-auto-ssl.
• Running sockproc in the background, and getting permissions right can lead to some funky installation/runtime issues. While for the most part, things should be automatic and I think this is working for most users, various different installations can lead to edge-case issues (a decent number of GitHub issues can probably be traced back to this, but here's a few random examples that seem like they could be related: unauthorized access too hook server (hook secret did not match) #121, Change log level when chmod fails ? #114, start_sockproc: line 55: kill: (47) - No such process #98
• Installing sockproc requires a build process involving make and gcc, which means lua-resty-auto-ssl can only be installed via LuaRocks, and not OpenResty's OPM: Deploy an OPM package? #45 While there's nothing wrong with LuaRocks, and OPM may eventually support modules that require compiling, it would be nice to be able to support OPM installs.

With the ACME v2 protocol now finalized, this idea has been increasingly on my mind. On the one hand, creating a pure Lua ACME client implementation will require a decent amount of new work, but the prospect of being able to ditch the reliance on sockproc is appealing (not that there's anything wrong with sockproc, but it just complicates our setup/installation and architecture).

If we wanted to go down this path, my general idea has been the creation of 1 or 2 new Lua libraries:

• OpenSSL bindings: We need some way to create new certificates directly in Lua and do the lower-level OpenSSL things (that dehydrated currently does with the openssl command line tools). luaossl could be used, although this is a C-based module, which means it can only currently be installed via LuaRocks (so no OPM). I've recently been toying around with a lua-openssl-ffi module to perform everything in OpenSSL via FFI (which means nothing in C needs to be compiled, so this could be installed via OPM).
• ACME client: My idea had been to create a new lua-resty-acme library that would use the OpenSSL library and lua-resty-http to actually implement the ACME v2 protocol. lua-resty-auto-ssl would still exist as a higher-level library that used lua-resty-acme (lua-resty-acme would only implement the protocol, playing a similar role to dehydrated, while lua-resty-auto-ssl would still perform all the nginx integration, SNI-based registration, certificate storage, etc.).

So again, I'm not sure if/when this will happen, but I at least wanted to get some of these ideas finally out there in a more concrete format.

[dvigueras]

I think this would be a great idea. Getting rid of sockproc and dehydrated will decrease the complexity of the whole process, probably leading to fewer bugs (e.g. the recent bug related to the agreement of Let's Encrypt terms in dehydrated).

👍

[dvigueras]

Have you checked out this project? https://github.com/fffonion/lua-resty-acme

This project uses a FFI-based openssl backend.