On Apr 14, 2016, at 3:50 PM, Joerg Sonnenberger <jo...@britannica.bec.de> wrote:
>
> On Thu, Apr 14, 2016 at 03:32:48PM -0600, Warren Young wrote:
>> STEP 1: Split your “server” configurations
>
> I don't think this is necessary at all.
It is. We want the proxy server to redirect all Fossil-over-HTTP requests to
HTTPS, which means URLs may be interpreted differently depending on the
protocol you use.
It is only all other URLs that are interpreted the same irrespective of the
protocol.
There’s also no point to serving Let’s Encrypt’s challenge/response files over
HTTPS. They’re only needed during the ACME negotiation, which always proceeds
over HTTP, else you couldn’t bootstrap the system.
>> STEP 2: Prepare for the Let’s Encrypt challenge/response sequence
>
> This part can just statically go into the same server block, no need for
> a separate file.
My nginx server serves four different sites, and I wanted the generated SSL key
to be good for all of them. If you don’t extract this to an include file, you
have to repeat it in each site’s server { } block.
For each domain you give to letsencrypt via the -d flag, Let’s Encrypt’s ACME
service repeats the challenge/response process. If any domain given via -d
returns a 404 error when the ACME service attempts to access
/.well-known/acme-challenge/* on that domain name, the cert generation process
will fail.
Thus, you must repeat this block in each server { } block for which you give a
-d flag, else the whole process fails. Let’s Encrypt won’t just skip over them
and give you a key for a subset of the domains you requested. It’s
all-or-nothing.
>> STEP 3: Write the wrapper script
>
> Personally, I would recomment just using the SSH FUSE binding and doing
> the dance from a separate machine. No need to have letsencrypt and all
> dependencies running on a server.
Fossil only does user authentication and permission management over HTTP. If
you serve it over plain SSH, all users effectively get admin-level privileges
on the repository, which is only acceptable when serving a private repo among
trusted colleagues.
There are games you can play with OpenSSH configuration files to get
Fossil-over-HTTP-over-SSH and thus still let Fossil do user/permission
management, but that’s about as complex to set up as this nginx proxying
scheme. It’s an ongoing complexity, too: for every user you add, you must
duplicate the SSH configuration hackery to give them access to the Fossil repo.
Whereas with HTTPS proxying, it’s a one-shot effort.
The only advantage SSH has here over HTTPS is that it doesn’t require you to
use a centralized PKI for keys; it’s perfectly acceptable to use decentralized
PSKs with SSH. Now that we have Let’s Encrypt, the disadvantages of a
centralized PKI in the TLS case disappear.
>> Let’s Encrypt certs only last for 90 days, which means it’s an ongoing
>> task to keep this up-to-date. Until Let’s Encrypt learns about safe
>> nginx configuration file modification, it’s a manual process. (With
>> Apache, letsencrypt-auto sets up a background auto-renewal process so
>> you can’t forget to renew. You could script this manually for nginx,
>> if you wanted.)
>
> Given that it is *not* supposed to change the configuration on renewal
> at all, that's a non-issue.
The nginx configuration doesn’t change, but the content of the *.pem files *do*
change on each renewal. If you don’t re-generate those files and reload the
nginx configuration every 90 days at most, it continues to serve those
now-expired certs until you do. With HSTS enabled, that means clients that
obey the HSTS demand will stop talking to your server, because they were told
to only accept HTTPS, and they refuse to talk to an HTTPS server with an
expired cert.
Something I forgot to mention in the article is that we created the
letsencrypt-wrapper script instead of just giving the command in the script
interactively because the renewal process is basically “re-run the wrapper and
restart nginx”. So, you could cron that process to run every 80 days or so,
avoiding the risk of locking your users out by forgetting to renew the cert.
I’m still wary of doing that, since I’ve had server upgrades empty the crontab
files so that all the scheduled jobs don’t run any more. You only discover
this after you get the tech support call.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
