CertBotを構成しようとしていますが、http経由でサイトにサービスを提供する場合にのみ機能します。通常、httpsリダイレクトがあり、certbotを使用する必要があるたびにサイト構成を変更する必要はありません。 /.well-known/
over 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
w/proxy_pass
ディレクティブを使用していませんでした(これも~
BTWを許可していません)。しかし、これをHTTPSブロックで使用することには何の問題もありませんでした。さらに https://serverfault.com/a/1018199/31279 と
https://serverfault.com/a/1017720/31279 Webアプリケーションの「実際の」ルートディレクトリを実際に渡す必要がないことに気付きました。ファイルの読み取り/書き込み。また、1つのディレクトリで複数のサイトにサービスを提供できるため、location
nginxサーバーブロック内にdefault
を追加するのが最も上手であると判断しました。 certbotを含めると、構成を100%調整せずにドメインを追加できるようになります。実際、nginxを実行するだけで、Webアプリを実行する必要さえありません。
これが私の新しいdefault
サーバーブロックです。注:私はnginxの「実際の」ウェブルート内にフォルダacme
を作成し、そのディレクトリに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経由でチャレンジを提供することは問題ありません。ただし、チャレンジは常にポート80を使用するプレーンなHTTP接続から始まり、ポート443でのみHTTPSにリダイレクトできます。
HTTP-01チャレンジの実装では、最大10リダイレクトまでのリダイレクトが行われます。 「http:」または「https:」へのリダイレクトとポート80または443へのリダイレクトのみを受け入れます。IPアドレスへのリダイレクトは受け入れません。 HTTPS URLにリダイレクトされると、証明書は検証されません(このチャレンジはbootstrap有効な証明書を対象としているため、途中で自己署名または期限切れの証明書に遭遇する可能性があります)。
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
nginxがルートディレクトリにアクセスできる場合、certbotには必要ありません。 .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;
}
}