> On 14 Jan 2017, at 22:31, William A Rowe Jr <[email protected]> wrote: > > On Sat, Jan 14, 2017 at 12:15 PM, Dirk-Willem van Gulik > <[email protected]> wrote: >> >> On 14 Jan 2017, at 19:05, William A Rowe Jr <[email protected]> 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.
Technically there is no need from this from a lets-encrypt perspective. Just port 80 for a few seconds. > 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. So the process of registering afresh; sending the tokens and getting the certs takes seconds at the very most. So I’d be quite willing to allow a server to not start up an stay in a very simple mode prior to this. An option may be to suid/chroot and what not down - and just hand the child a filedescriptor to which it has write only for just the key - after which it dies. But fair to assume we can hold of starting the server; it is pretty common to see 2-3 seconds of cycle time due to DNS and what not already. And anyone who understands/cares can do a dead normal setup using SSL thing-a-me’s. or am I getting the scope wrong ? > 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.) Agreed - but think that this is an ortogonal isue - and have sofar found that with things like chipcards and HSM - the openssl engines are doing splendidly. Dw.
