平成 27 年台風第 15 号が，我が町を通過いたしました。

りりさん，こんにちは。

ありがとうございます。

そうですね。庭木の枝が折れたり，チロリアンランプの棚が落ちたり，庭一面に，木の葉が散らばったりと，まあ，いろいろです。いつもながらの台風一過ですが，思いのほか風が強かったので，庭木さんたちも大変だったようです。

とはいえ，我が家の被害は，大したことはありませんでした。我が町は，ほぼ，直撃だったので，もうちょっと大変なことになるかなと心配していたんですが。

くりくりさん，こんばんは。

「（緊急）BIND 9.10.2/9.9.7の脆弱性（DNSサービスの停止）について」の件ですね。またまた，でっかいですねぇ。本当に，お疲れさまです。
笑っちゃいけないのですが，次文の後半の表現に受けてしまいました（爆）。「本脆弱性により、DNSサービスの停止が発生する可能性があります。また、本脆弱性を利用した攻撃はリモートから可能です。」

くりくりさん，おはようございます。

NGINX の HTTP/2 パッチは 1 回目のアルファバージョンなんですね。いろいろ問題が残っているでしょうから，テストでやっているとはいえ， 公開サイトで使うと結構大変かもです。でも，フィードバックを送ってあげると，あちらの開発の手助けにはなりますよ。

> まだ検証中なのかもしれませんね。
そうなんでしょうか， SECURE.PHP.NET ？

私も，テスト環境で全サイトの HTTPS 化の検証をやっているのですが，クリアできない問題がいろいろあって。妥協しちまえばいいんですがね。

そういえば， 8 月初めに， Let’s Encrypt でスケジュールの変更がアナウンスされてましたね。あちらも船出は手間取っているようです。

くりくりさん，こんにちは。

体調はいかがですか。

> 文章を読んで朝から自分なりに考えているんですが
ありがとうございます。無理をされないでください。といいつつ，以下，ちょっと書き続けます（汗）。

> http://morilog.com/wordpress/tips/wp_redirect/
上記はまだ試していませんが，リダイレクトというのは，いずれにしろ， URI が変わると思うんです。違いますか。今のところ試したリダイレクト関係だと，すべて URI が変わってしまいました。そうすると，その変わった URI で改めてネゴシエーションが行われるんです。ここが大問題でして。

例えば，ドキュルートに WordPress をインストールし， https://example.com にアクセスするとトップページが表示される状態だとします。このとき， https://admin.example.com にアクセスすると，まず SSL のネゴシエーションが行われますよね。次に， WordPress の表示のためには， https://example.com でないといけないので，ここに跳ばすと，そちらの証明書で確認が行われるので，エラーが出てしまいます。 https://example.com と https://admin.example.com に使う証明書が同じなら何も問題は起きないのですが， https://admin.example.com でクライアント認証を行うためにこちらには自前 CA を使おうと画策しているので，こんなことが起こってしまいます。

これが，静的サイトだと，
<VirtualHost 192.168.xxx.xxx:443>
DocumentRoot "documentroot"
<Directory "documentroot">
Options FollowSymLinks
AllowOverride FileInfo
Require 192.168.xxx.xxx
SSLCipherSuite sslciphersuite
SSLVerifyClient require
SSLVerifyDepth 1
</Directory>
ServerName admin.example.com
</VirtualHost>
<VirtualHost 192.168.xxx.xxx:443>
DocumentRoot "documentroot"
<Directory "documentroot">
Options FollowSymLinks
AllowOverride FileInfo
Require all granted
</Directory>
ServerName example.com
</VirtualHost>
とでもしておけば簡単にできました。で， rel=”canonical” href=”https://example.com” でも入れておけばいいかと。

ところが， WordPress だと，いろいろハードルが高くなるんです。表示したい WordPress の実体が同一というのが，一つの肝になります。 https://example.com であろうと https://admin.example.com であろうと，同じデータベースにアクセスして同じコンテンツを表示しないといけないわけでして。 https://admin.example.com でアクセスしているのだが，内部的には， https://example.com で処理しているという具合になります。この辺を乗り切るには， PHP スクリプトで処理しないとダメなのかなと思ったのですが，どうでしょうか？

両方に別の WordPress をインストールして，動きとしては，お互いがミラーみたいな動きにするしかないのでしょうか。それも，ややこしいなぁ。

ところで話変わって。
質問者の方が，
> こちらの環境でIE11でjavascriptを切っても変化はありませんでした。
とお書きですが， Win10 上の IE11 でも，やはり JavaScript で引っかかっているように見えました。でも，「 WordPress でないサイトでも同じ現象が起こる」とお書きなので，やはり，ちがう理由なんでしょう。リロードしたときに，ほぼ毎回，待機中とか応答待ちとかのメッセージが出るのですが， WordPress でないサイトでも同じ現象が起こるのなら，サーバ設定に原因ありですかねぇ。