https://the.example.com
を介してWebサイトを提供したい(したがって、非標準のサブドメインを使用したい)が、同じWebサイトにhttps://example.com
およびhttps://www.example.com
(+ the http
対応物)。
したがって、https://www.example.com/page
と入力するとhttps://the.example.com/page
にリダイレクトされ、http://example.com/page
と入力すると同じページにリダイレクトされます。
これをnginxでhttp
に次のように作成しました:
server {
listen 80;
server_name example.com www.example.com the.example.com;
return 301 https://the.example.com$request_uri;
}
非標準のhttps
URLのこのブロック:
server {
listen 443 ssl http2;
server_name www.example.com example.com;
location /.well-known/ {
allow all;
}
location / {
return 301 https://the.example.com$request_uri;
}
}
そして、実際の(正規の)ウェブサイトのためのこのブロック:
server {
listen 443 ssl http2;
server_name the.example.com;
location ...
}
簡潔にするために、ほとんどの行は省略しました。実際のサイトに移動する前に、リダイレクトを1つだけ指定します。
http
- siteと正規のhttps
- siteは機能しますが、https://www.example.com
とhttps://example.com
で証明書の問題が発生します。
次の3つの証明書を要求しました。
certbot certonly --webroot -w "/some/root" -d www.example.com -m [email protected] --agree-tos
certbot certonly --webroot -w "/some/root" -d example.com -m [email protected] --agree-tos
certbot certonly --webroot -w "/some/root" -d the.example.com -m [email protected] --agree-tos
これはどのように機能するはずですか?サブサイトには独自のwebroot
が必要ですか、それともWebルートや証明書を共有する必要がありますか?何が起こっているのか私はここで少し迷っています...
メインドメインだけでなく、複数のサブドメインにも同じサーバー構成を使用できます。ただし、.well-known/acme-challenge
SSLなしのポート80:
# The canonical site: we want this in our addressbar
server {
listen 443 ssl http2;
server_name husker.example.com;
ssl_certificate /etc/letsencrypt/live/husker.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/husker.example.com/privkey.pem;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
}
server {
listen 443 ssl http2;
server_name www.example.com secure.example.com example.com;
# same certificates, different server because of redirect
ssl_certificate /etc/letsencrypt/live/husker.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/husker.example.com/privkey.pem;
# This redirects everything else to the canonical address
location / {
return 301 https://husker.example.com$request_uri;
}
}
server {
listen 80;
server_name husker.example.com;
server_name www.example.com secure.example.com example.com;
# Allow anyone to view the acme-challenge; certbot needs this
location /.well-known/acme-challenge {
allow all;
root /var/www/certbot/;
}
# This redirects everything else to the canonical address
location / {
return 301 https://husker.example.com$request_uri;
}
}
証明書を要求すると、 すべてのドメインを1行に入力する必要があります :
certbot certonly --webroot -w "/some/root" -d example.com -d www.example.com -d secure.example.com -m [email protected] --agree-tos
これにより、最初のドメインがサブジェクトとしてリストされた1つの証明書が作成されます。この場合はexample.com
をクリックし、残りのドメインを SubjectAlternativeName
として追加します。
ドメインには個別の構成が必要です:www.example.com
およびexample.com
server {
listen 443 ssl http2;
server_name www.example.com;
ssl_certificate www.example.com.crt;
ssl_certificate_key www.example.com.key;
location /.well-known/ {
allow all;
}
location / {
return 301 https://the.example.com$request_uri;
}
}
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate example.com.crt;
ssl_certificate_key example.com.key;
location /.well-known/ {
allow all;
}
location / {
return 301 https://the.example.com$request_uri;
}
}
あなたの設定で
次の3つの証明書を要求しました。
certbot certonly --webroot -w "/some/root" -d www.example.com -m [email protected] --agree-tos
certbot certonly --webroot -w "/some/root" -d example.com -m [email protected] --agree-tos
certbot certonly --webroot -w "/some/root" -d the.example.com -m [email protected] --agree-tos
各ドメイン構成は、独自の証明書ファイルとキーを指す必要があります
証明書がワイルドカードでない場合*example.com