Невозможно использовать LetsEncrypt - CertBot - Когда настроено перенаправление HTTP на HTTPS

Обновление: моя основная проблема заключалась в том, чтобы не использовать $request_uri ж / proxy_pass директива (которая также не позволяет ~ Кстати). Но нет ничего плохого в использовании этого в блоке HTTPS. Более того, посмотрев на оба https://serverfault.com/a/1018199/312793 и

https://serverfault.com/a/1017720/312793 Я понял, что мне не нужно передавать мой «настоящий» корневой каталог моего веб-приложения, просто где-то, что nginx может служить certbot для чтения / записи файлов. Кроме того, у вас может быть один каталог для обслуживания нескольких сайтов, поэтому я решил, что будет наиболее целесообразно добавить location внутри default Серверный блок nginx У меня есть настройка перенаправления неправильно отформатированных запросов для включения certbot, поэтому теперь я могу добавлять домены без настройки каких-либо конфигураций на 100%. На самом деле, веб-приложение даже не нужно запускать, только nginx.

Вот мой новый default серверный блок. Примечание: я создал папку acme внутри моего "настоящего" корневого каталога nginx и обслуживаю этот каталог для location /.well-known/acme-challenge/

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        root /var/www/html/;
        index index.html;
}
server {
        listen 443 default_server;
        listen [::]:443 default_server;
        ssl_certificate /etc/ssl/fake/fake.crt;
        ssl_certificate_key /etc/ssl/fake/fake.key;

        location /.well-known/acme-challenge/ {
        root /var/www/html/acme;
         allow all;
        }

        root /var/www/html/;
        index index.html;
}

Как и при настройке, вам нужно иметь что-то для сертификатов SSL, иначе nginx не запустится правильно. Очень доволен такой настройкой / разрешением!

Необходимо добавить следующее: $request_uri

location /.well-known/acme-challenge/ {
    proxy_pass              http://localhost:8575/$request_uri;
    include                 /etc/nginx/conf.d/proxy.conf;
}

С участием HTTP-01 вызов Вполне нормально сначала перенаправить на HTTPS и решить проблему через TLS. Однако проблема всегда начинается с простого HTTP-соединения, использующего порт 80, и вы можете перенаправить на HTTPS только через порт 443.

Наша реализация запроса HTTP-01 следует за перенаправлениями, глубина до 10 перенаправлений. Он принимает перенаправления только на «http:» или «https:» и только на порты 80 или 443. Он не принимает перенаправления на IP-адреса. При перенаправлении на URL-адрес HTTPS он не проверяет сертификаты (поскольку эта задача предназначена для загрузки действительных сертификатов, по пути он может встретить самозаверяющие или просроченные сертификаты).

Запрос HTTP-01 может быть выполнен только на порту 80. Разрешение клиентам указывать произвольные порты сделает запрос менее безопасным, поэтому он не разрешен стандартом ACME.

Следовательно, такая конфигурация Nginx также должна работать:

server {
    listen 80;
    server_name www.example.com example.com;

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

server {
    listen 443 ssl;
    server_name www.example.com example.com;

    location /.well-known/acme-challenge/ {
        # HTTP-01 challenge
    }

    location / {
        # Your web application
    }
}

В вашем случае это означает, что следующее может быть либо в HTTP, либо в HTTPS server блок.

location /.well-known/acme-challenge/ {
    proxy_pass   http://localhost:8575/.well-known/acme-challenge/;
    include      /etc/nginx/conf.d/proxy.conf;
}

Вы смогли заменить /.well-known/acme-challenge/ с участием $request_uri так как:

Когда переменные используются в proxy_pass:

location /name/ {
    proxy_pass http://127.0.0.1$request_uri;
}

В этом случае, если в директиве указан URI, он передается на сервер как есть, заменяя исходный URI запроса.

Кроме того, если / имеет тот же корень, вам не нужен отдельный location вообще.

В вашей конфигурации proxy_pass не требуется для certbot, если nginx имеет доступ к корневому каталогу. Вы можете просто разрешить доступ для .well-known каталог и объявить server_name и root для сайта.

Я написал об этом для сообщения в блоге (https://dev.slickalpha.blog/2019/11/installing-lemp-stack-on-debian-buster.html).

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;
    root /var/www/example.com/site;
    location ~ /.well-known/acme-challenge/ {
       allow all;
    }
    location / { 
       return 301 https://$server_name$request_uri;
    }
}