www付きのサブドメインをSSLドメインに転送できなかったときのメモ
2020年06月21日 プログラミングTIPS
httpのwwwアクセスをhttpsのwwwなしドメインにリダイレクトすることはできるのに、httpsのwwwアクセスをhttpsのwwwなしドメインにリダイレクトできなかったときのメモです。
あらかじめWebサーバーのNginxで、サブドメインwww付きのアクセスはすべてwwwなしにリダイレクトするように設定していました。例えば、「http://www.zapanet.info/blog/」にアクセスすると、SSL対応の「https://zapanet.info/blog/」に転送できるようにしていました。
ところが、「https://www.zapanet.info/blog」にアクセスしても、「https://zapanet.info/blog/」には転送されなくて失敗しました。httpからhttpsには転送できるのに、httpsからhttpsには転送できませんでした。なんででしょう？
Webサーバー側の設定はできているはずなのに、なぜかエラーが起きて転送されません。「この接続ではプライバシーが保護されません」と表示されてしまいます。常時SSL化はしてあるはずなのに。
なんでかなぁとよく考えたら、取得したSSL証明書がサブドメインに対応していないからでした。「zapanet.info」はSSL化していましたが、「www.zapanet.info」はSSL化していなかったということです。
では、どうするか。
取得したSSL証明書は、「Let's Encrypt - フリーな SSL/TLS 証明書」です。
Let's Encryptで、サブドメインも含めたSSL証明書に更新すれば良かったというわけです。最初にCentOS8のサーバー上でcertbot-autoコマンドで取得した証明書は以下でした。
あらかじめWebサーバーのNginxで、サブドメインwww付きのアクセスはすべてwwwなしにリダイレクトするように設定していました。例えば、「http://www.zapanet.info/blog/」にアクセスすると、SSL対応の「https://zapanet.info/blog/」に転送できるようにしていました。
ところが、「https://www.zapanet.info/blog」にアクセスしても、「https://zapanet.info/blog/」には転送されなくて失敗しました。httpからhttpsには転送できるのに、httpsからhttpsには転送できませんでした。なんででしょう？
Webサーバー側の設定はできているはずなのに、なぜかエラーが起きて転送されません。「この接続ではプライバシーが保護されません」と表示されてしまいます。常時SSL化はしてあるはずなのに。
なんでかなぁとよく考えたら、取得したSSL証明書がサブドメインに対応していないからでした。「zapanet.info」はSSL化していましたが、「www.zapanet.info」はSSL化していなかったということです。
では、どうするか。
取得したSSL証明書は、「Let's Encrypt - フリーな SSL/TLS 証明書」です。
Let's Encryptで、サブドメインも含めたSSL証明書に更新すれば良かったというわけです。最初にCentOS8のサーバー上でcertbot-autoコマンドで取得した証明書は以下でした。
certbot-auto certonly --webroot -w ファイルのあるディレクトリ -d zapanet.info
あらたにwwwのサブドメイン付きのSSL証明書に更新するには以下のようにします。「-d」でサブドメイン入りのURLを並べていけばいいというわけです。
上記のようにすると、すでに証明書は存在しているがexpandするのか？と聞かれるので、拡大してrenewします。それでもできますが、正しい書き方はexpandオプションを付けてこうです。
SSL証明書を更新したら、Webサーバーを再起動（再読み込み）します。すると、「https://www.zapanet.info/blog」のアクセスが「https://zapanet.info/blog/」に転送されるようになりました。
「SSLでサブドメイン付きだとなぜ転送されない？」という悩みは、SSL証明書のせいでした。Let's Encryptでサブドメインまで取得していなかったのが原因でした。転送したいサブドメインががある場合は、メインのドメインに加えてサブドメインも含めてSSL証明書を取得しておきましょう。
ところが、他のドメインでSSL証明書を更新し、再びそのドメインのwww付きでアクセスしてみたところ、今度はブラウザ上で証明書が違うと怒られました。「ERR_CERT_COMMON_NAME_INVALID」と表示されます。なぜでしょう？
CN（コモンネーム）を確認したり、SAN（サブジェクト）を確認したり、いろいろ確認しました。両方ともなぜか違う設定になっていました。「今新しく取得したのになぜ？」とハマりました。
原因は、nginx.confの転送設定におけるserverディレクティブの記述ミスでした。最初はポート80のhttpだけ転送設定していたので、そこにポート443のhttps転送のみを追加したのが間違いでした。SSL接続を転送するわけなので、転送用のディレクティブ内にもSSL証明書を読み込むように設定しないといけませんでした。
はまった原因は、最初に設定したドメインを「default_server」にしていたためです。そのため、きちんとSSL証明書を読み込めないドメインのSSL処理がすべてデフォルトサーバーで処理されていました。結果として、違うドメインでアクセスしているのに、デフォルトサーバーの間違ったSSL証明書が読み込まれていました。通りでCNもSANもおかしな設定になっていたわけです。これでは安全に通信できるわけがありません。
原因がわかったので、nginx.confを正しく設定したところ、複数ドメインでも問題なく転送できるようになりました。
certbot-auto certonly --webroot -w ファイルのあるディレクトリ -d zapanet.info -d www.zapanet.info上記のようにすると、すでに証明書は存在しているがexpandするのか？と聞かれるので、拡大してrenewします。それでもできますが、正しい書き方はexpandオプションを付けてこうです。
certbot-auto certonly --webroot --expand -w ファイルのあるディレクトリ -d zapanet.info -d www.zapanet.infoSSL証明書を更新したら、Webサーバーを再起動（再読み込み）します。すると、「https://www.zapanet.info/blog」のアクセスが「https://zapanet.info/blog/」に転送されるようになりました。
「SSLでサブドメイン付きだとなぜ転送されない？」という悩みは、SSL証明書のせいでした。Let's Encryptでサブドメインまで取得していなかったのが原因でした。転送したいサブドメインががある場合は、メインのドメインに加えてサブドメインも含めてSSL証明書を取得しておきましょう。
バーチャルサーバーの設定ではまった話
上記のやり方でサブドメイン転送に成功したので、他のドメインにも同様に適用しようとしました。ところが、他のドメインでSSL証明書を更新し、再びそのドメインのwww付きでアクセスしてみたところ、今度はブラウザ上で証明書が違うと怒られました。「ERR_CERT_COMMON_NAME_INVALID」と表示されます。なぜでしょう？
CN（コモンネーム）を確認したり、SAN（サブジェクト）を確認したり、いろいろ確認しました。両方ともなぜか違う設定になっていました。「今新しく取得したのになぜ？」とハマりました。
原因は、nginx.confの転送設定におけるserverディレクティブの記述ミスでした。最初はポート80のhttpだけ転送設定していたので、そこにポート443のhttps転送のみを追加したのが間違いでした。SSL接続を転送するわけなので、転送用のディレクティブ内にもSSL証明書を読み込むように設定しないといけませんでした。
はまった原因は、最初に設定したドメインを「default_server」にしていたためです。そのため、きちんとSSL証明書を読み込めないドメインのSSL処理がすべてデフォルトサーバーで処理されていました。結果として、違うドメインでアクセスしているのに、デフォルトサーバーの間違ったSSL証明書が読み込まれていました。通りでCNもSANもおかしな設定になっていたわけです。これでは安全に通信できるわけがありません。
原因がわかったので、nginx.confを正しく設定したところ、複数ドメインでも問題なく転送できるようになりました。