こんにちは、オフィスピコッツの小笹です。
第25話で、新サイト「あの場所のつづき」をWordPressで立ち上げた話を書きました。
その途中、一つ引っかかったのがSSLです。
正式なサイトURLは、
https://anobasho.net
wwwなしで使う予定です。
レンタルサーバー側で無料SSLを設定すると、こちらは正常に「保護されています」へ変わりました。
ところが、
www.anobasho.net
だけは、
「SSLを設定できません」
のままです。
最終的には、www付きのアクセスだけをCloudflareで受け取り、wwwなしのHTTPSへ301転送する構成にしました。
今回は、その設定を進めた記録です。
wwwなしは保護済み、www付きだけ設定できない
今回の構成では、ドメインをCloudflare Registrarで取得し、WordPressは既存のレンタルサーバーへ設置しています。
ドメインを管理する場所と、Webサイトのデータを置く場所が別です。
CloudflareのDNSでは、wwwなしとwww付きのアクセス先を設定しました。
サーバー側で無料SSLを申し込むと、wwwなしは処理が完了しました。
一方、www付きには、
「SSLを設定できません」
という表示が残りました。
ここで気をつけたのは、原因を勝手に決めないことです。
待てば直るのか。
DNSの設定なのか。
サーバー側の仕様なのか。
今回、www側が申し込めない根本原因までは特定していません。
最終的に行ったのも、その原因を取り除く方法ではなく、Cloudflare側でwwwアクセスを受ける別の経路を作る対応です。
転送するだけでも、HTTPSならwww側の証明書がいる
正式URLがwwwなしなら、
「wwwで来たらwwwなしへ飛ばせばいい」
と考えます。
HTTPなら分かりやすいのですが、
https://www.anobasho.net
へアクセスされた場合、転送する前にまずHTTPS接続を成立させる必要があります。
そのため、www側にも有効な証明書が必要です。
CloudflareのSSL/TLS設定を確認すると、Universal SSL証明書の対象に、
- anobasho.net
- *.anobasho.net
が含まれていました。
状態はActiveです。
つまりCloudflare側には、wwwを含む第1階層のサブドメインを受ける証明書があります。
ただし、証明書が存在することと、その通信が実際にCloudflareを通ることは別です。
DNS側でプロキシされていなければ、Cloudflareの証明書を訪問者へ出す経路にはなりません。
ここを分けて考える必要がありました。
最初にAIから出た転送設定には警告が出た
Cloudflareの「Rules」からwww転送を作ります。
最初にAI社員から案内されたRequest URLは、
*://www.anobasho.net/*
という形でした。
転送先はwwwなしのHTTPSです。
入力すると、Cloudflare側から、
プロトコルを明示するよう促す警告
が表示されました。
この段階で、
「AIがそう言ったからそのまま保存」
とはしませんでした。
画面をスクリーンショットで見せます。
AI側も案を変更しました。
HTTPとHTTPSを別々のルールにする。
という方針です。
wwwのHTTPとHTTPSを2本に分けた
最終的に登録した転送ルールは2本です。
HTTPSから来た場合
Request URL：
https://www.anobasho.net/*
転送先：
https://anobasho.net/${1}
ステータスコードは301。
クエリ文字列も保持します。
HTTPから来た場合
Request URL：
http://www.anobasho.net/*
転送先：
https://anobasho.net/${1}
こちらも301です。
つまり、
http://www.anobasho.net/abc/
でも、
https://www.anobasho.net/abc
でも、
最終的には、
https://anobasho.net/abc
へ移します。
パスも残します。
?check=1
のような情報も保持する設定です。
Deploy時に、今度はDNSの警告が出た
転送ルールを保存するとき、Cloudflareから別の警告が出ました。
wwwのDNSレコードが、
DNS only
のままだからです。
転送ルールはCloudflare上で動きます。
ところがDNS onlyでは、wwwへの通信はCloudflareのプロキシを通りません。
つまり、
「ルールは作ったけれど、そのルールへ通信が来ない」
状態になり得ます。
今回はこちらの警告内容と、これから行う作業が一致していました。
先に転送ルールを保存。
その後でDNSのwwwレコードを、
DNS only → Proxied
へ変更します。
wwwなし側はDNS onlyのままです。
最終的な役割は、
- www付き → Cloudflareが受けて転送
- wwwなし → レンタルサーバー側のSSLで通常表示
という分担です。
ルールがActiveでも、まだ完了にはしない
2つの転送ルールを登録すると、一覧ではどちらもActiveになりました。
でも、最近のAI社員実践記では何度も出てくる話ですが、
「設定画面でActive」と「実際の利用者が使える」は別です。
最後はブラウザで確認します。
HTTPでもHTTPSでもwwwなしへ移動した
シークレットウィンドウで、
を開きます。
wwwなしのHTTPSへ移動。
次に、
こちらも同じです。
証明書警告は出ず、wwwなしのトップページが表示されました。
さらに、
https://www.anobasho.net/submit/?check=1
のように、ページの場所とクエリ文字列を付けたURLでも確認しました。
こちらもwwwなし側へ移動します。
これで今回必要だった、
www付きで来ても正式URLへ案内できる
状態になりました。
ただし「SSL問題の原因を解決した」とは書かない
今回の結果だけを見ると、
「wwwのSSL問題を解決した」
と言いたくなります。
でも、正確には少し違います。
レンタルサーバー側で、
なぜwww付きだけ無料SSLを設定できなかったのか
という根本原因は特定していません。
今回は、
www付きの通信をCloudflare側で受ける構成へ変更した
ことで、利用者がwww付きHTTPSでもアクセスできるようにしました。
原因究明と、利用できる状態にすることは別です。
この辺りは、AIとの技術作業の記事では意識して分けるようになりました。
AIの設定案は、実画面で直していく
今回も、最初から完璧な設定値が出てきたわけではありません。
最初の転送ルールでは警告が出ました。
wwwをDNS onlyのままルールをDeployしようとしたときにも警告が出ました。
そのたびに、
画面を見る。
スクリーンショットをAIへ見せる。
今の構成に合わせて手順を直す。
という進め方です。
AIへ、
「Cloudflareでwww転送する方法を教えて」
と聞いて、一度返ってきた答えをそのまま実行して終わりではありません。
現物の画面を見ながら調整する。
第24話で書いたサーバーのタイムゾーンと同じです。
一般的に正しい手順が、今の環境でそのまま正しいとは限りません。
「設定できた」より「実際に動いた」を記録する
今回、スクリーンショットをかなり残しました。
SSLの状態。
Cloudflareの証明書。
警告。
転送ルール。
DNS。
最終確認。
こういう途中画面は、その場では、
「もう終わったからいらない」
と思いがちです。
でも、後から記事にすると、
どこでAIの案を変えたのか
が分かります。
正解だけ残すより、
「最初はこうした」
「警告が出た」
「そこでこう変えた」
の方が、実践記としては価値があります。
AI社員実践記で残したいのは、
完璧なマニュアルではなく、
実際に作業した記録
だからです。
今回確認していないことも残す
今回、ブラウザではwww付きHTTP・HTTPSからwwwなしHTTPSへ移動することを確認しました。
ただし、まだ確認していないものもあります。
たとえばHTTPレスポンスヘッダーを使った詳細な検証。
www経由でフォームPOSTした場合の挙動。
Universal SSLの長期的な証明書更新。
wwwなしのHTTPをHTTPSへ統一する別の設定。
こうした部分まで、
「全部確認済み」
とはしません。
今回確認したのは、
ブラウザで必要なURLを開き、想定どおり移動・表示できたところまで。
です。
今回の結論
第25話で作った「あの場所のつづき」は、WordPressとしては動きました。
ただ、その途中で、
wwwなしはSSL済み、www付きだけ設定不可
という状態が残りました。
そこでCloudflare側のUniversal SSLと転送ルールを使い、
www付きのHTTP・HTTPSを、
wwwなしのHTTPSへ301転送。
wwwのDNSだけをProxiedへ変更しました。
最後はブラウザで、
- HTTPのwww
- HTTPSのwww
- 下層ページ＋クエリ付きURL
を確認。
wwwなしへ移動するところまで確認しています。
そして今回も、
AIが最初に出した案は、そのままでは通りませんでした。
でも、実画面の警告を見せれば修正できます。
技術の知識そのもの以上に、
実際の画面とAIの説明が合っているかを一つずつ確認すること
の方が大切なのかもしれません。
AI社員実践記は、まだ続きます。
- AI標本木：https://pikoz.net/ai-hyohonboku/
- 一見さんテスト：https://pikoz.net/ichigen-test/
- 新しい取り組み一覧：https://pikoz.net/atarashii-torikumi/
- AI社員実践記：https://pikoz.net/category/ai-jissen/
京都産業21 登録専門家（No.46）／滋賀県DX協創パートナー／デジタル庁 デジタル推進委員。2002年開業、創業25年目。京都・滋賀を中心に1万件超のWeb活用・制作に携わる。 会社概要を見る