Невозможно использовать LetsEncrypt - CertBot - Когда настроено перенаправление HTTP на HTTPS
Я пытаюсь настроить CertBot, и он работает, только когда я обслуживаю свой сайт через http. Обычно у меня есть перенаправление https, и я не хочу менять конфигурацию сайта каждый раз, когда мне нужно использовать certbot. Я пытался обслуживать только /. Well-known / через http, но у меня все еще нет идей, как решить эту проблему?
Я пытаюсь скопировать эту идею, но не работает -> NGINX перенаправляет все, кроме letsencrypt, на https
Например: Это работает:
server {
listen 80;
listen [::]:80;
server_name example.com www.example.com;
location / {
proxy_pass http://localhost:8575/;
include /etc/nginx/conf.d/proxy.conf;
}
}
Это не работает: (Обратите внимание, что текущие настроенные сертификаты SSL неверны, но необходимы для запуска NGinX)
server {
listen 80;
listen [::]:80;
server_name www.example.com example.com;
location /.well-known/acme-challenge/ {
proxy_pass http://localhost:8575/;
include /etc/nginx/conf.d/proxy.conf;
}
location / {
return 301 https://$server_name$request_uri;
}
}
server {
listen 443 ssl;
listen [::]:443;
server_name www.example.com example.com;
# ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
# ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_certificate /etc/ssl/crt/crt.crt;
ssl_certificate_key /etc/ssl/crt/key.key;
location / {
proxy_pass http://localhost:8575/;
include /etc/nginx/conf.d/proxy.conf;
}
}
Журнал ошибок:
certbot | Saving debug log to /var/log/letsencrypt/letsencrypt.log
certbot | Plugins selected: Authenticator webroot, Installer None
certbot | Registering without email!
certbot | Obtaining a new certificate
certbot | Performing the following challenges:
certbot | http-01 challenge for www.example.com
certbot | http-01 challenge for example.com
certbot | Using the webroot path /var/www/html for all unmatched domains.
certbot | Waiting for verification...
certbot | Challenge failed for domain www.example.com
certbot | Challenge failed for domain example.com
certbot | http-01 challenge for www.example.com
certbot | http-01 challenge for example.com
certbot | Cleaning up challenges
certbot | IMPORTANT NOTES:
certbot | - The following errors were reported by the server:
certbot |
certbot | Domain: www.example.com
certbot | Type: unauthorized
certbot | Detail: Invalid response from
certbot | http://www.example.com/.well-known/acme-challenge/WyVEA5g6BWVDPpYUhEJ0bG5iH6daF1rZpFd0vuTXOa0
certbot | [50.117.156.123]: " <!DOCTYPE html><html lang=\"en-US\">\r\n
certbot | \t<head>\n\n\t\t <meta charset=\"UTF-8\">\r\n <meta
certbot | name=\"viewport\" con"
certbot |
certbot | Domain: example.com
certbot | Type: unauthorized
certbot | Detail: Invalid response from
certbot | https://www.example.com/x61_h9wxFY2Ye8-16GllyMq_dfsXbsEB1lYOjeq4LjU
certbot | [50.117.156.123]: " <!DOCTYPE html><html lang=\"en-US\">\r\n
certbot | \t<head>\n\n\t\t <meta charset=\"UTF-8\">\r\n <meta
certbot | name=\"viewport\" con"
certbot |
certbot | To fix these errors, please make sure that your domain name was
certbot | entered correctly and the DNS A/AAAA record(s) for that domain
certbot | contain(s) the right IP address.
certbot | - Your account credentials have been saved in your Certbot
certbot | configuration directory at /etc/letsencrypt. You should make a
certbot | secure backup of this folder now. This configuration directory will
certbot | also contain certificates and private keys obtained by Certbot so
certbot | making regular backups of this folder is ideal.
certbot | Some challenges have failed.
certbot exited with code 1
Обновление: моя основная проблема заключалась не в использовании директивы $ request_uri с proxy_pass (которая также не разрешает ~ BTW). Но нет ничего плохого в использовании этого в блоке HTTPS. Более того, посмотрев на https://serverfault.com/a/1018199/312793 и
https://serverfault.com/a/1017720/312793 , я понял, что не На самом деле нет необходимости передавать мой «настоящий» корневой каталог моего веб-приложения, просто где-то, что nginx может служить certbot для чтения / записи файлов. Кроме того, у вас может быть один каталог для обслуживания нескольких сайтов, поэтому я решил, что будет наиболее целесообразно добавить местоположение внутри блока сервера nginx по умолчанию , который я настроил для перенаправления неправильно отформатированного запросы на включение certbot, поэтому теперь я могу добавлять домены без настройки каких-либо конфигов на 100%. На самом деле, веб-приложение даже не нужно запускать, только nginx.
Вот мой новый серверный блок по умолчанию . Примечание: я создал папку acme в моем «реальном» веб-корневом каталоге nginx и обслуживаю этот каталог для местоположения /.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;
}
В вашей конфигурации proxy_pass не требуется для certbot, если nginx имеет доступ к корневому каталогу. Вы можете просто разрешить доступ к . Широко известному каталогу и объявить имя_сервера и 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;
}
}
С запросом 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 .
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 :
местоположение / имя / { proxy_pass http: //127.0.0.1$request_uri; }В этом случае, если в директиве указан URI, он передается в сервер как есть, заменяя исходный URI запроса.
Кроме того, если / имеет тот же корень, вам вообще не нужно отдельное расположение .