Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Error on Let's encrypt auto renewal (Nginx)

I am trying to set up greenlock-express to run behind nginx proxy.

Here is my nginx config

...
# redirect
server {
    listen 80;
    listen [::]:80;
    server_name mydomain.com;

    location / {
        return 301 https://$server_name$request_uri;
    }
}

# serve
server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name mydomain.com;

    # SSL settings
    ssl on;
    ssl_certificate C:/path/to/mydomain.com/fullchain.pem;
    ssl_certificate_key C:/path/to/mydomain.com/privkey.pem;

    # enable session resumption to improve https performance
    ssl_session_cache shared:SSL:50m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # enables server-side protection from BEAST attacks
    ssl_prefer_server_ciphers on;
    # disable SSLv3(enabled by default since nginx 0.8.19) since it's less secure then TLS
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

    # ciphers chosen for forward secrecy and compatibility
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';

    # enable OCSP stapling (mechanism by which a site can convey certificate revocation information to visitors in a privacy-preserving, scalable manner)
    resolver 8.8.8.8 8.8.4.4;
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate C:/path/to/mydomain.com/chain.pem;

    # config to enable HSTS(HTTP Strict Transport Security) https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security
    add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload";

    # added to make handshake take less resources
    keepalive_timeout 70;

    location / {
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_set_header X-NginX-Proxy true;
        proxy_pass https://127.0.0.1:3001/;
        proxy_redirect off;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}
...

I have node server running on port 3000 (http) and port 3001 (https). Everything else seems to be working, but certificates do not update and expire after 3 months.

If I closed nginx and ran node server on port 80 (http) and port 443 (https), then it updates certs.

I made sure that .well-known/acme-challenge is forwarded to node server, i.e when I go to url http(s)://mydomain.com/.well-known/acme-challenge/randomstr I get following response:

{ 
  "error": { 
    "message": "Error: These aren't the tokens you're looking for. Move along." 
  } 
}
like image 580
Timo Avatar asked Mar 07 '18 15:03

Timo


2 Answers

The easy way to separate the webroot for ACME authentication.

Create a webroot directory for ACME authentication.

C:\www\letsencrypt\.well-known

In the nginx configuration, set the webroot for ACME authentication to the previously created directory.

http://example.com/.well-known/acme-challenge/token -> C:/www/letsencrypt/.well-known/acme-challenge/token

server {
    listen 80;
    listen [::]:80;
    server_name mydomain.com;

    location ^~ /.well-known/acme-challenge/ {
        default_type "text/plain";
        root C:/www/letsencrypt;
    }

    location / {
        return 301 https://$server_name$request_uri;
    }
}

Restart nginx.

You can change your webroot in certbot to get authentication again.

certbot certonly --webroot -w C:\www\letsencrypt\ -d exapmle.com --dry-run

First, test it by adding the --dry-run option. Otherwise, you may experience issues limiting the number of authentication attempts.

like image 166
Been Kyung-yoon Avatar answered Sep 23 '22 08:09

Been Kyung-yoon


The error you are seeing is that when a token is placed in your

webroot/.well-known/acme-challenge/token

Then Let’s Encrypt tries to verify that from the internet. going to http://yourdomain/.well-known/acme-challenge/token it gets a 404 error - page not found. Exactly why it get’s a 404 I can’t be certain. If you place a file there yourself, is it reachable from the internet ?.

If you are wondering there are a couple of automatic ways to renew your SSL's without restarting your nginx. The one most nginx users seem to prefer is the webroot plugin: first, obtain a new cert using something like:

certbot certonly --webroot -w /path/to/your/webroot -d example.com --post-hook="service nginx reload"

Then set up a cron job to run certbot renew once or twice a day; it will only run the post-hook when it actually renews the certificate. You can also use --pre-hook flag if you prefer to stop nginx to run certbot in standalone mode.

There’s also a full nginx plugin, which you can activate with --nginx. It’s still being tested, so experiment at your own risk and report any bugs.

Note: post-hookFlag will take care of reloading nginx upload renewal of your certs

like image 29
Yousaf Avatar answered Sep 22 '22 08:09

Yousaf