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