httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: mod_lets-encrypt
Date Sat, 14 Jan 2017 21:31:57 GMT
On Sat, Jan 14, 2017 at 12:15 PM, Dirk-Willem van Gulik
<dirkx@webweaving.org> wrote:
>
> On 14 Jan 2017, at 19:05, William A Rowe Jr <wrowe@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.)

Mime
View raw message