Share

Question

I am trying to add another domain (www.curiotech.me) to my SSL certificate, which there are currently one, curiotech.me. I get the following error when running sudo certbot certonly --webroot --webroot-path=/var/www/html -d www.curiotech.me

Failed authorization procedure. www.curiotech.me (http-01): urn:acme:error:unauthorized :: The client lacks sufficient authorization :: Invalid response from http://www.curiotech.me/.well-known/acme-challenge/IB6wCaFDO8bqQt_tndM7__txPdZrahYEz-ifuLLrLQ0: "<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>"

Answer 1

hansen May 15, 2017

Hi @parion

Is your website root located in /var/www/html for both curiotech.me and www.curiotech.me ?

Report

parion May 15, 2017

Actually, no. Since this is a node app, the website server is located in /home/gwiebel/app
Report
- hansen May 15, 2017
  
  @parion
  Okay, then that’s your problem.
  
  sudo certbot certonly --webroot --webroot-path=/home/gwiebel/app -d www.curiotech.me
  
  Report
  
  parion May 15, 2017
  
  So I actually ran this command, silently cursing to myself for missing this, but I still get the same error.
  
  Report

Answer 2

parion May 15, 2017

Actually, no. Since this is a node app, the website server is located in /home/gwiebel/app
Report
- hansen May 15, 2017
  
  @parion
  Okay, then that’s your problem.
  
  sudo certbot certonly --webroot --webroot-path=/home/gwiebel/app -d www.curiotech.me
  
  Report
  
  parion May 15, 2017
  
  So I actually ran this command, silently cursing to myself for missing this, but I still get the same error.
  
  Report

Answer 3

hansen May 15, 2017

@parion
Then you need to post your Nginx server block, so we can see where it might go wrong, since you’re doing proxy_passthru to Node.js, but static files should be served by Nginx.

Report

parion May 16, 2017

# HTTP - redirect all requests to HTTPS:
server {
        listen 80;
        listen [::]:80 default_server ipv6only=on;
        return 301 https://$host$request_uri;
}

# HTTPS - proxy requests on to local Node.js app:
server {
        listen 443;
        server_name curiotech.me www.curiotech.me;

        ssl on;
        # Use certificate and key provided by Let's Encrypt:
        ssl_certificate /etc/letsencrypt/live/curiotech.me/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/curiotech.me/privkey.pem;
        ssl_session_timeout 5m;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

        location ~ /.well-known {
                allow all;
        }

        # Pass requests for / to localhost:5000:
        location / {
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-NginX-Proxy true;
                proxy_pass http://localhost:5000/;
                proxy_ssl_session_reuse off;
                proxy_set_header Host $http_host;
                proxy_cache_bypass $http_upgrade;
                proxy_redirect off;
        }
}

Report

hansen May 16, 2017
@parion
Can you change the first server block to this:

server { listen 80; listen [::]:80 default_server ipv6only=on; root /home/gwiebel/app; location ~ /.well-known { allow all; } }

Then check the config and restart Nginx:

sudo service nginx configtest sudo service nginx restart

Then run the certificate again:

sudo certbot certonly --webroot --webroot-path=/home/gwiebel/app -d curiotech.me -d www.curiotech.me

Then change the block to this:

server { listen 80; listen [::]:80; server_name curiotech.me www.curiotech.me; return 301 https://$server_name$request_uri; }

Then check the config and restart Nginx:

sudo service nginx configtest sudo service nginx restart
Report
- parion May 16, 2017
  
  That did it! Thanks!
  
  Report
  
  hansen May 16, 2017
  
  Remember to setup the cronjob, so it automatically renews every week, because LE certificates are only valid for 90 days, so by it should automatically renew on about day 60 - and you’ll start getting warnings on day 75 (or something like that).
  
  If you haven’t already certbot in your crontab, then follow the guide below. I’m not sure how certbot in Ubuntu 16.04 is handled, so don’t know if it is already added to the crontab.
  
  Run this command to ensure the path of certbot:
  
  /usr/bin/certbot renew
  
  Then run sudo crontab -e to open the crontab in your editor and add the following line to the bottom:
  
  23 4 * * 1 /usr/bin/certbot renew --quiet --post-hook "/usr/sbin/service nginx restart"
  
  This will run certbot in quiet mode, meaning it will only show errors and certbot-updates notification. And then whenever it has updated a certificate, it will restart Nginx, since Nginx doesn’t dynamically load the new certificate.
  It’s being run at 4:23am on every Monday (that’s the 1) - you can change that if you want. This is based on your servers time.
  
  Report

Answer 4

parion May 16, 2017

# HTTP - redirect all requests to HTTPS:
server {
        listen 80;
        listen [::]:80 default_server ipv6only=on;
        return 301 https://$host$request_uri;
}

# HTTPS - proxy requests on to local Node.js app:
server {
        listen 443;
        server_name curiotech.me www.curiotech.me;

        ssl on;
        # Use certificate and key provided by Let's Encrypt:
        ssl_certificate /etc/letsencrypt/live/curiotech.me/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/curiotech.me/privkey.pem;
        ssl_session_timeout 5m;
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
        ssl_prefer_server_ciphers on;
        ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';

        location ~ /.well-known {
                allow all;
        }

        # Pass requests for / to localhost:5000:
        location / {
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-NginX-Proxy true;
                proxy_pass http://localhost:5000/;
                proxy_ssl_session_reuse off;
                proxy_set_header Host $http_host;
                proxy_cache_bypass $http_upgrade;
                proxy_redirect off;
        }
}

Report

hansen May 16, 2017
@parion
Can you change the first server block to this:

server { listen 80; listen [::]:80 default_server ipv6only=on; root /home/gwiebel/app; location ~ /.well-known { allow all; } }

Then check the config and restart Nginx:

sudo service nginx configtest sudo service nginx restart

Then run the certificate again:

sudo certbot certonly --webroot --webroot-path=/home/gwiebel/app -d curiotech.me -d www.curiotech.me

Then change the block to this:

server { listen 80; listen [::]:80; server_name curiotech.me www.curiotech.me; return 301 https://$server_name$request_uri; }

Then check the config and restart Nginx:

sudo service nginx configtest sudo service nginx restart
Report
- parion May 16, 2017
  
  That did it! Thanks!
  
  Report
  
  hansen May 16, 2017
  
  Remember to setup the cronjob, so it automatically renews every week, because LE certificates are only valid for 90 days, so by it should automatically renew on about day 60 - and you’ll start getting warnings on day 75 (or something like that).
  
  If you haven’t already certbot in your crontab, then follow the guide below. I’m not sure how certbot in Ubuntu 16.04 is handled, so don’t know if it is already added to the crontab.
  
  Run this command to ensure the path of certbot:
  
  /usr/bin/certbot renew
  
  Then run sudo crontab -e to open the crontab in your editor and add the following line to the bottom:
  
  23 4 * * 1 /usr/bin/certbot renew --quiet --post-hook "/usr/sbin/service nginx restart"
  
  This will run certbot in quiet mode, meaning it will only show errors and certbot-updates notification. And then whenever it has updated a certificate, it will restart Nginx, since Nginx doesn’t dynamically load the new certificate.
  It’s being run at 4:23am on every Monday (that’s the 1) - you can change that if you want. This is based on your servers time.
  
  Report

LetsEncrypt failed authorization process

Leave a Comment

Share

Share your Question

LetsEncrypt failed authorization process

Leave a Comment

Related

question

Setting up correct path for Web and Ftp user account

question

SSH blocked for all droplet's only on my region.

question

Common name mismatch

question

Best practice setting users and permissions for multiple Wordpress sites

Almost there!