On Sat, Jan 14, 2017 at 12:15 PM, Dirk-Willem van Gulik <di...@webweaving.org> wrote: > > On 14 Jan 2017, at 19:05, William A Rowe Jr <wr...@rowe-clan.net> wrote: > > Any mod_letsencrypt can provision the certs but needs to do so > while still root, before servicing requests (although there could be > some bounce-step where the MPM begins satisfying requests, > including the verification request necessary for letsencrypt.) We > certainly don't want to parse any web response whatsoever while > running as root. > > Some of this will be needed - we need to be root to bind to port 80 — as the > protocol (in my reading) seems to demand it (now would be a good time to > petition the draft to change this for a random higher port). > > In fact - that may be a nice feature - an, essential, empheral port.
My thinking was more along the lines that we fork off a process, much like mod_cgid or mod_ftp does to handle low numbered ports. What is actually handed across the domain socket or equivalent is structured simply enough to not be harmed by an errant child process, or if needed by the server earlier, then forked with the lesser run-as-httpd user permissions to speak some predictable and strictly constructed message back up to the root parent process. It might be nice to our users if the cert/key isn't in the keystore, that the server starts anyways with a dummy cert, until it finally resolves to the letsencrypt CA server and completes that handshake. The server can respond to that child process modifying the keystore and exiting by initiating a graceful restart to begin serving traffic with the newly obtained cert/key material. Somewhere in this equation lies accessor functions to mod_ssl to allow us access to keystores. Which would be a very useful facility, well beyond just letsencrypt. Whether those cert/key pairs live in ldap or some other place. Imagine a small cluster, say 4 instances of httpd, where only one performs the letsencrypt dance and the others search a memcache or other remote resource for the resulting cert/key materials (locked down well, we would hope.)
