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.
> 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.
> 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.
> STEP 5: Create the base SSL/TLS configuration
> ------
>
> We extracted the site configuration from our server { } blocks above because
> we now need to create a second such block for each site that nginx serves.
>
> server {
> include local/ssl;
> include local/site;
> }
>
> That is, instead of including the letsencrypt-challenge file — since we only
> serve the Let’s Encrypt challenge/response sequence via HTTP — we include the
> following SSL configuration file:
>
> listen 443 ssl;
>
> ssl on;
No need for "ssl on" in combination with the ssl on the listen line --
means all the config can be shared with plain HTTP.
> 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.
Joerg
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
