httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <di...@webweaving.org>
Subject Re: mod_lets-encrypt
Date Sun, 15 Jan 2017 13:28:52 GMT

> On 14 Jan 2017, at 22:31, William A Rowe Jr <wrowe@rowe-clan.net> wrote:
> 
> 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.

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.
Mime
View raw message