vsalapataras
By:
vsalapataras

Drupal 8 App - Lets encrypt problem

April 6, 2017 1.7k views
Let's Encrypt Drupal Ubuntu

I follow this [https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-14-04](http:://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-14-04) but the result is:
IMPORTANT NOTES:

  • The following errors were reported by the server:

Domain: <my_domain>
Type: unauthorized
Detail: Invalid response from
http://<my_domain>/.well-known/acme-challenge/aFAMmKoQThGwkXAQup0P8TMCrEn4plZnWdTpHSPo0nU:
"<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>"

Domain: <my_domain>
Type: unauthorized
Detail: Invalid response from
http://<my_domain>/.well-known/acme-challenge/BY0BiDxz6KTzaRj0wiB7kSaWFyBlKW2syexQBw9Kk:
"<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>"

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address.

I have replace my domain with <my_domain> for this question.
Help me please!!!

Log In to Comment
4 Answers
hansen April 6, 2017

Did you add the following to your server block configuration and restart Nginx?

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

Or maybe you have some other location block, which overrules this location?

Reply
vsalapataras April 6, 2017

This is my configuration file. Of cource it is the first step. But the problem exist...can you find something wrong?

server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;

    server_name <nmy_domain> www.<my_domain>;

    root /var/www/html/drupal;
    index index.html index.php  index.htm;

    error_page 404 /404.html;
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root /usr/share/nginx/html;
    }

    location = /favicon.ico {
        log_not_found off;
        access_log off;
    }

    location = /robots.txt {
        allow all;
        log_not_found off;
        access_log off;
    }

    location ~ \..*/.*\.php$ {
        return 403;
    }

    location ~ ^/sites/.*/private/ {
        return 403;
    }

    location ~ (^|/)\. {
        return 403;
    }

    location / {
        try_files $uri @rewrite;
    }

    location @rewrite {
        rewrite ^ /index.php;
    }

    # Workaround Drupal bug #2583799 - https://www.drupal.org/node/2583799
    rewrite ^/core/authorize.php/core/authorize.php(.*) /core/authorize.php?$1 permanent;

    location ~ '\.php$|^/update.php' {
        fastcgi_split_path_info ^(.+?\.php)(|/.*)$;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_intercept_errors on;
        fastcgi_pass unix:/var/run/php5-fpm.sock;
    }

    location ~ ^/sites/.*/files/imagecache/ {
        try_files $uri @rewrite;
    }

    location ~ ^/sites/.*/files/styles/ {
        try_files $uri @rewrite;
    }

    location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
        expires max;
        log_not_found off;
    }
    location ~ /.well-known {
        allow all;
    }
}
Reply
  • hansen April 6, 2017

    Replace this part from your configuration:

        location ~ (^|/)\. {
        return 403;
    }

    With this configuration and restart Nginx:

        location ~ (^|/)\. {
        deny all;
    }

    That should work. If not, simply remove that location block.

jtittle1 April 6, 2017

@vsalapataras

CertBot is under heavy active development and many things change that may not be included in the guides provided by DigitalOcean until they are updated.

For example, the current home page is https://certbot.eff.org/.

The recommended way to install CertBot is now:

sudo add-apt-repository -y ppa:certbot/certbot \
&& sudo apt-get update \
&& sudo apt-get install certbot

You would then use certbot instead of certbot-auto.

You can check the new documentation here: https://certbot.eff.org/docs/

It's sometimes hard to keep up with all the changes, so don't get too frustrated. It's simply the nature of development and since LetsEncrypt and CertBot are still new, there's probably more changes to come (hopefully, of course, for the better).

How you go about creating a certificate depends on how you want to set things up. There is a plugin for NGINX, though I normally do things manually (my preference).

For the NGINX plugin, you'd run something such as:

certbot --nginx -d domain.com -d www.domain.com

You can also skip the common questions using something such as:

certbot --nginx --agree-tos -n -d domain.com -d www.domain.com -m you@domain.com

The above supplies your e-mail address in the command so you're not prompted for it and also runs it in non-interactive mode. It auto auto-agrees to the TOS.

If you want to do everything manually (my preference), you'd run something such as:

certbot certonly --agree-tos -n -d domain.com -d www.domain.com -m you@domain.com

The above command doesn't install anything, it just creates the certificates and tells you where they are stored. You'd then modify your server block(s) and add the correct configuration.

Reply
vsalapataras April 6, 2017

Thank you for the answer but again i have the same proble...IMPORTANT NOTES:

  • The following errors were reported by the server:

Domain: <>
Type: unauthorized
Detail: Invalid response from
http://<>/.well-known/acme-challenge/wt2grWQSZzPdVVhifOFuj7zpAnlhf4oB3GMzenzQxQA:
"<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>"

To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address.

Reply
  • jtittle1 April 6, 2017

    @vsalapataras

    Which command did you use?

    Generally, if you use certonly, you need to stop NGINX, run the command, then restart NGINX. The reason for this is because certonly, and standalone have to be able to bind to ports 80 + 443. If NGINX is occupying them (as would be the case when it's running), it fails.

    That's why the NGINX plugin was made available -- to get around that -- but it's not 100% and is, last I recall, still in beta. It may work for some, but may not work for many.

    If you're using --nginx, try shutting down NGINX and running the second command that I used in my previous response.

    service nginx stop

    Then:

    certbot certonly --agree-tos -n -d domain.com -d www.domain.com -m you@domain.com

    If that works, then all you'd need to do is modify your server block and add the directives needed for SSL, then restart NGINX.

    If the above works, let me know and I'll provide you with what's needed to convert that server block over. If it doesn't work, then something else would appear to be wrong as I've never had a single issue with certonly when the domain is pointing to the correct IP.

Have another answer? Share your knowledge.

Related Questions