Nginx Active-Passive HA

NashBrydges

@dafyre said in Nginx Active-Passive HA:

    location /.well-known/acme-challenge {
        root /var/www/letsencrypt;
     }

So I understand it well, these lines are ONLY to tell Let's Encrypt which folders to look to for the challenge/response and has nothing to do with any actual site webroot folders. Am I correct? This is just used so Nginx can act as the web server for those challenges/responses.

dbeato

@black3dynamite said in Nginx Active-Passive HA:

Using well-known path looks like a better approach.

https://community.letsencrypt.org/t/auto-renewal-with-nginx-without-downtime/7814/2

https://community.letsencrypt.org/t/auto-renewal-with-nginx-without-downtime/7814/4

https://github.com/mbrugger/letsencrypt-nginx-docker/blob/master/README.md

I just setup that yesterday on my NGINX Proxy.

dafyre

@nashbrydges said in Nginx Active-Passive HA:

@dafyre said in Nginx Active-Passive HA:
    location /.well-known/acme-challenge {
        root /var/www/letsencrypt;
     }
So I understand it well, these lines are ONLY to tell Let's Encrypt which folders to look to for the challenge/response and has nothing to do with any actual site webroot folders. Am I correct? This is just used so Nginx can act as the web server for those challenges/responses.

Right. But any website you want to protect with SSL, you add this into the server {} section for each site... so if you have my.domain.conf, and nextcloud.domain.conf, you'd have to put the code in each of those files in the server {} sections.

Edit: here's the full config for that site:

server {
       listen         80;
       server_name    my.domain.com
       return         301 https://$server_name$request_uri;

        location /.well-known/acme-challenge {
            root /var/www/letsencrypt;
         }
}

server {
 listen 443 ssl;

 server_name my.domain.com

 client_max_body_size 10G;
 fastcgi_buffers 64 4K;
 proxy_send_timeout     7200;
 send_timeout   7200;

 add_header Strict-Transport-Security "max-age=15552000; includeSubdomains;" always;
 ssl on;
 ssl_certificate /etc/nginx/certs/my.domain.com/fullchain.pem;
 ssl_certificate_key /etc/nginx/certs/my.domain.com/privkey.pem;
 ssl_protocols  TLSv1.1 TLSv1.2;
 ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

 location / {
  proxy_pass http://my.ip.addr.ess;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;

}

 location /.well-known/acme-challenge {
    root /var/www/letsencrypt;
 }

}

NashBrydges

@dafyre Awesome! Thanks for clarifying that. I don't have any expiring certs for the next 40 days so I'll keep a look out to see how this works.

NashBrydges

Assuming this is going to work as planned, back to the original question...setting up Nginx HA and certs management. Which approach is best/recommended?

Let each Nginx server manage its own certs and renewals?
Only have one manage certs and renewals and copy certs to second node?
Use Let's Encrypt --duplicate option (here)?
None of the above?

dafyre

@nashbrydges said in Nginx Active-Passive HA:

Assuming this is going to work as planned, back to the original question...setting up Nginx HA and certs management. Which approach is best/recommended?

Let each Nginx server manage its own certs and renewals?

Only have one manage certs and renewals and copy certs to second node?

Use Let's Encrypt --duplicate option (here)?

None of the above?

I see no reason approach #2 won't work. The private keys are under /etc/letsencrypt with the actual certs themselves too.

Just use rsync with the appropriate switches to preserve permissions and such.

dbeato

I have this for my well-known on my Nginx Proxy
0_1520451668608_DeepinScreenshot_select-area_20180307144017.png

JaredBusch

@dafyre said in Nginx Active-Passive HA:

@nashbrydges said in Nginx Active-Passive HA:

Assuming this is going to work as planned, back to the original question...setting up Nginx HA and certs management. Which approach is best/recommended?

Let each Nginx server manage its own certs and renewals?

Only have one manage certs and renewals and copy certs to second node?

Use Let's Encrypt --duplicate option (here)?

None of the above?

I see no reason approach #2 won't work. The private keys are under /etc/letsencrypt with the actual certs themselves too.

Just use rsync with the appropriate switches to preserve permissions and such.

I would definitely do #2.

JaredBusch

@NashBrydges side question. If you setup the .well-known to work correctly, why do you then need the HA? because nginx will never be down except for the momentary reload after the certs are updated.

NashBrydges

@jaredbusch said in Nginx Active-Passive HA:

@NashBrydges side question. If you setup the .well-known to work correctly, why do you then need the HA? because nginx will never be down except for the momentary reload after the certs are updated.

That certainly addresses the biggest concern about a long downtime during the renewall process for a high number of certs and probably addresses most concerns with this client. He's already running Veeam replication to a second box so his RTO and RPO are relatively short and within his business tolerance.

Having said that, it's a great learning opportunity for me to set this up in my lab, if for no other reason than to try it and see how it works.

JaredBusch

@nashbrydges said in Nginx Active-Passive HA:

@jaredbusch said in Nginx Active-Passive HA:

@NashBrydges side question. If you setup the .well-known to work correctly, why do you then need the HA? because nginx will never be down except for the momentary reload after the certs are updated.

That certainly addresses the biggest concern about a long downtime during the renewall process for a high number of certs and probably addresses most concerns with this client. He's already running Veeam replication to a second box so his RTO and RPO are relatively short and within his business tolerance.

Having said that, it's a great learning opportunity for me to set this up in my lab, if for no other reason than to try it and see how it works.

Certainly no reason not to do it for a lab. and for a proxy with as much as it sounds like you have in production, it will still be a likely good solution.