当社はIT技術のオンライン教育を得意としたセミナー専門会社です。

ITエンジニアの技術力UPをお約束します。

SSLサーバ移転に注意すべきこと(転送mod_rewriteが効かない場合の考察)

SSLサーバ移転に注意すべきこと(転送mod_rewriteが効かない場合の考察)


昨年(平成30年)からSSL仕様にする流れが大きくサーバトラブルの要因となるケースが発生している、特にサーバ移転や表示ドメインの変更時に注意が必要だ。これは何を意味しているかというと、概ね以下の問題点が出てくるためである。


SSLでサーバ移転で生ずる問題

  1. 旧httpドメインでのアクセスを取りこぼしたくないから転送処理を導入するが期待通りに動作しない
  2. SSL証明書をwww付きで取得するか、無しで取得するかでWEBサーバ設定やmod_rewrite等が影響を受ける
  3. 転送のキャッシュ、証明書のキャッシュは「強制リロード」、「履歴の削除」、「キャッシュの削除」では消えない場合がある。

SSL証明書を購入するときに注意をしないといけないのは「www]付きのドメインなのか否かである。SSL証明書発行局のブランドにより1つの証明書で「www付き」と「www無し」をサポートしてくれるものが中にはある。申請時点でwww.xxxx.comのようにコモンネームにwwwをつけた場合(あり・なしを双方サポート)するパターンがあるので申請時にどのコモンネームにするかはよく考えたほうが良い。以前はwww.xxxx.comだったがサーバ移転のタイミングでSSLにしてwww無しで行こうと考える場合は一番注意が必要だ。



つまりwww無しにしたとして、旧ドメインはwww付きであるためユーザの中には旧ドメインでアクセスしてくるものもいるだろう。それを取りこぼししないようにmod_rewriteを使ってwwwで来たものを無しに転送するといった手法は古くからある。しかし、SSLが絡んでくると複雑な状況になる。というのもSSLが付いているサーバアクセスではブラウザー側の挙動が転送処理をチェックする前にSSLのチェックを先に実施するパターンがあるからだ。


ここで発生する問題はwww無しでSSL取得したが、以前はwwwが付いていたのでそれをどうやって取りこぼしをしないように統合するかである。結論を先に言ってしまうと残念ながらSSL証明書はwww付きとwww無しの双方をサポートするSSL商品を購入するか、www付きとwww無しを個別に2つ購入するしかない。


その理由はブラウザー側にあり、SSLでアクセスするモードでは転送処理より優先してSSLチェックが発生するからである。chrome,opera,vivaldi等では転送前にSSLチェックは生じないがedge,safari,firefoxではSSLチェックが転送より先に発生するのである。つまり転送処理をいくら入れてもwww付きSSLがなかったり、wwwドメインがサイトに存在しないと「セキュリティに問題があるサイト」という判定になってしまうため転送まで行き着かないのである。

タグ: , , ,

https化で出てくる問題(https化した途端にmod_rewriteが効かなくなってしまう)


Google Chromeの7月リリースバージョンでいよいよサイトのALL SSL化が始まる。
これによりhttpに対応していないサイトは「このサイトは安全でない」の画面が出てしまう。今でも
稀に見ることがある画面ですが、あの画面がでてしまったら当然誰もクリックor タップしないでしょう 。

ということでSSL化をしなければ行けないわけだけど、もう一つこれには考慮が必要なことに気づいた。
スマホとPCコンテンツを分離して作成している場合はアノテーション設定が必要だが、モバイルファーストインデックスも
開始宣言(2/21)が出ているし、何よりもアノテーション設定でURLをhttpsに変更しなければならない。

※レスポンシブで制作している場合は気にする必要はありません。WORDPRESSでデバイスプラグインを使っている人も問題なし

ということでSSL化をやってみると色々な新規顧客である特有の問題が出た。
一番ハマったのが、「https化した途端にmod_rewriteが効かなくなってしまう。httpのときにはmod_rewrite使えたのに!」という現象のサーバが幾つかあった。
つまりWORDPRESSなどではカスタムパーマリンクが使えなくなってしまう現象に遭遇しました。

原因を調べるために、約1日考え込み実験をしまくりました。
や~、これは気が付かなかった。httpd.confを普段触らずVirtualHostでサイト定義するから頭がそちらに向かなかった。
なんとhttpd.confを調べたら下記のようになっているではないですか! なるほど、それではTOPからその設定になっていると
下位で設定したコンフィグは無視されますね!

httpd.conf 修正前)

httpd.conf CentOSの場合修正後)

apache2.conf Ubuntuの場合修正後)



apacheを再起動してめでたくmod_rewriteがSSLで使えるようになりました。
上記の設定はDirectoryディレクティブを使用しているため、適切に範囲設定をその環境内で
望ましい設定を厳密には行う必要があります。上記のケースでは”/”でAllowOverride Allにしているためセキュリティを
高くするためにはフォルダーの範囲をもう少し狭めたほうが良い場合もあるので実験して良いバランスの設定を考慮スべきと思います。

他にも、https化で出てくる作業が多いのでメモをしておきます。

https化で遭遇する付帯作業

  • Google Search Consoleにhttpsでサイト登録が必要
  • 旧httpアドレスがインデックスされたり、他サイトと連携している場合はhttpアドレスからhttps転送設定が必要
  • 転送設定をjavascriptでやる場合は注意が必要。コンバージョンが拾えなくなる可能性がある。リファラーを追加する設定が必要かも
  • Google Analysticsの管理画面でプロパティ、ビューのURLをhttpsに切り替える。ビューのコンバージョンURLも変更。
  • sitemap.xmlをhttpsのアドレスになっているかチェック、なっていなかったら作り直し
  • WORDPRESSのプラグイン経由でanalysticsを設定、取得している場合は再設定が必要になる場合が多い

タグ: , , , ,