(reshuffled top post)

On 14 Jan 2017, at 16:07, Rich Bowen <rbo...@rcbowen.com> wrote:
> On Jan 10, 2017 12:15 PM, "Jacob Champion" <champio...@gmail.com 
> <mailto:champio...@gmail.com>> wrote:
> On 01/10/2017 08:35 AM, Dirk-Willem van Gulik wrote:
> Before I send someone into the woods - did anyone consider/do a quick
> ‘mod_lets_encrypt’ (with or without a persistent store) — that
> requires virtually no configuration ?
> 
> Considered? Yes. Back in August there was some discussion on this list with 
> Josh Aas. I don't know what the current status is.
..
> https://lists.apache.org/thread.html/ea902ae8e453b3a8d36345318fc74a54880d8bf14fed24e665c4b833@%3Cdev.httpd.apache.org%3E
>  
> <https://lists.apache.org/thread.html/ea902ae8e453b3a8d36345318fc74a54880d8bf14fed24e665c4b833@%3Cdev.httpd.apache.org%3E>
...
> https://lists.apache.org/thread.html/27d1fce7d30d9e31e2472045c260e4f8dcefd300a731ff9e435a5d4a@%3Cdev.httpd.apache.org%3E
>  
> <https://lists.apache.org/thread.html/27d1fce7d30d9e31e2472045c260e4f8dcefd300a731ff9e435a5d4a@%3Cdev.httpd.apache.org%3E>
> I talked with him at linuxcon, but there's been no followup. I for one would 
> love to see this happen.

So it seems we currently pull in enough sundry into mod_ssl to barely need 
something as ‘big’ as:

        https://github.com/kristapsdz/acme-client 

if we assume the HTTP method (only) — which makes sense if we assume that this 
module is first and foremost about zero configuration and convenience. 

By extend that also means we ‘trust’ ourselves and the user we start up as 
(prior to any fork, suid or chrooting).

So I think we can narrow this down a lot (I just had to put something like this 
into a simple XMPP system) - as anyone who wants to do something more complex 
can use the many scripts available or use ‘real’ CA request processes.

So we are talking about the configs which are as simple as

        # Defaults to /var/httpd/acme-private or something like we do for 
Mutexes.
        #
        ACMEDir /var/db/httpd/acme-private

        <VirtualHost foo.bar>
                ACME automatic
                …

Where this implies SSLEnable, a set of sane/best-practice. ‘A+’, set of 
baseline SSL directives w.r.t. OSCP stapling  and so on. And absolutely no 
further SSL statements in your vhost. And it implies that port 80 forwards to 
https. Perhaps disallow any port/listen stuff ?

If you need SSL statements — then you are out of scope ? Is that fair ?

Which reduces the footprint to:

-       fetching the ACME-CA-URLs on first run ever; on install —or— having 
these as part of the distribution.

        => Fair to assume we ship with the ACME CA url ?

-       pin the server.

-       reading -or- generating an RSA key & 0600 storing it in what we 
consider a safe enough place (prior to any chroot)ing. 

        => Fair to assume key rollover is out of scope for this key (we could 
even do this empheral - and regenerate on renewal) ?

        => Fair to assume we just use one for all domains ?

-       Register this on first run. 

        =>      Fair to assume things like contact email and EULA ok are out of 
scope ?

-       Build up a cert for each vhost; with all aliases added too as altnames. 

        - for each vhost (altname) — get a challenge from the ACME server.

        =>      Fair to assume we do not care about account recovery ?

-       bring up that/all vhost on their port 80  (all vhosts that have 
LetsEncrypt set to auto/on).
        
                => so if I understand the spec right - only port 80

                        ==>  thus fair to assume non-root startup is out of 
scope - as we need to bind to a port < 1024.

                So therefore:
                        => fair to configure this ‘easier’ — i.e. if you do 
LetsEnrypt on on a domain SSL auto switches on and port 80 becomes an automatic 
redirect to https ?

-       Respond to the well know URI with each of he challenges.

-       Fetch/poll for the cert; save with 0600 and tight UID and be done.

-       Gracefully fail for each domain after N seconds - blocking https and 
with a sorry no ACME on http.

        =>      do we need to allow for an ErrorDocument customisation of the 
latter ?

-       Set up a sane virtual SSL set of directives; and then chroot/suid/fork 
and start your normal run.

-       Switch of http or make http a blind to https forwarder.

-       Can we assume that the server has a graceful restart every week ? 

                => And thus declare ACME renewal from within out of scope  ?
        
        Or do we need to auto disable SSL and go to http ?

Does that make sense - or have I oversimplified it and lost the plot ?

Dw





Reply via email to