さぽろーぐ さぽろーぐ

WordPressサイトをSSL化したら別サーバーのウェブメールが使えなくなった

SSLサイトと非SSLサイトの話
シェア
ある日、WordPressホスティングでウェブを運用し、共用レンタルサーバーでメールを運用しているお客様から、「ウェブメール用のサイト(共用レンタルサーバー側)が表示されなくなった」とお問い合わせがありました。

別のスタッフが電話で受けたお問い合わせでしたが、昨日までは普通に見えていて、今はエラー表示が出るようになったという状況のようです。

メールサーバーには異常がないのにウェブメールが見えない

EX-CLOUDのWordPressホスティングは、ウェブサイトの運営に特化したものです。メールアドレスを作成する機能などはありません。そのため、独自ドメインでメールアドレスを作りたい場合、メール管理用の機能とGUIが使える別のホスティングサービスを追加で契約される方がいらっしゃいました。

今回のお客様も、ウェブ用にWordPressホスティングを、メール用の共用レンタルサーバーホスティングをそれぞれご契約されていた方でした。

「共用サーバーの管理画面から、ウェブメールのリンクをクリックしたら画面が見えなくなっている。数日前は見えていたのに」

数日前といえば、そのお客様の別契約側で、ウェブサイト(example.org)にSSLのインストール作業を行ったばかりでした。作業を行ったのは私ではなく別のスタッフで、今回お電話を受けたのもそのスタッフでした。

そして、今問題が発生しているのは、ウェブサイトのあるサーバーではなく、共用サーバーのウェブメール(webmail.example.org)の表示です。

「同じサーバーをご利用の別のお客様のウェブメールには異常はなさそうですが、お客様のウェブメールはエラー表示が出るようになっておりますね」

というスタッフの会話を聞きながら、私には思いあたる節がありました。電話対応が終了後、そのスタッフに声をかけてみました。

状況:
●A:ウェブサイト:https://example.org(WordPressホスティングのサーバー、SSL優先設定済み)→直近で作業したばかり。正常に閲覧できる

●B:ウェブメールサイト:http://webmail.example.org(共用サーバー、非SSL)→Aとは別サーバー。直近で何も作業を行っていない。サイトが閲覧できない??

赤影:「いままでアクセスしたことのないブラウザでアクセスしたら、ウェブメールサイトも見えませんかね」

スタッフ:「はい。見えますね。ほんとですね」

赤影:「管理画面内のウェブメールへのリンクをクリックするのではなくて、URLボックスに直接[http://webmail.example.org]と記載してページを読み込めば、見ることはできますよね」

スタッフ:「そうですね」

赤影:「おそらくSSLのインストールの仕方の影響かと思うので、私対応しますね」

kusanagi環境でのSSLサーバー証明書インストール作業

EX-CLOUDのWordPressホスティングは、1契約につき1ウェブサイトまでサポート範囲と定めており、希望者には追加料金なしで、JPRSのドメイン認証型SSLサーバー証明書の申請、インストール、WAF設定までを行っていました。

このホスティングプランにはCentOS 7 にkusanagiというWordPressに最適化された環境が搭載されていました。コマンドラインで、root権限の作業を行う必要がありますが、比較的シンプルな方法でサーバー証明書をインストールすることができます。具体的な順は以下の1から4です。

1)サーバー内に、サーバー証明書+中間証明書をつなげて作成した「証明書ファイル」と、「秘密鍵ファイル」を設置しておく

2)kusanagi コマンド発行するとウェブサーバーの設定に証明書設定が加わる(同時にウェブサーバーのリスタートが行われる)

# kusanagi ssl --cert 証明書のパス --key 秘密鍵のパス プロファイル

3)httpにアクセスが来たらhttpsにリダイレクトするためのコマンドを発行

# kusanagi ssl --https redirect プロファイル

4)HSTSを有効化するためのコマンドを発行

当初の手順書ではウェブサイトのホスト名ごとにコマンドオプションを変えていましたが、今回は、

# kusanagi ssl --hsts mid プロファイル

の「mid」のパラメーターにて設定していました。

※この対応の後、サポートスタッフの手順書についても「weak」のパラメーターでの設定を行うようになりました。

# kusanagi ssl --hsts weak プロファイル

mid / weak を含め、この辺りのコマンドはkusanagi固有の呼び方なので次章で概要を説明します。

原因となったのはHSTS、対象ドメインの範囲

HSTSとは常時SSL化を推奨する時代の流れで出てきた規格の一つで、HTTP(http://)で接続してきたアクセスに対して、ウェブサーバー側が次回以降はHTTPS(https://)で接続するように伝える機能です。「HTTP Strict Transport Security」の略です。

SSLサイトを運用するウェブサーバー側でHSTSを有効化しておくと、HTTPヘッダー情報の中にStrict Transport Securityを有効にしているという内容が含まれるようになります。一度そのサイトにアクセスした同じブラウザから、次回、同サイトへアクセスを行う際はHTTPS(https://)サイトへ優先して接続を行うようになります。

ヘッダー情報には有効期限があるため、2回以降の接続であっても期限を過ぎていたら、その設定は解除されます。

ウェブサーバーのHSTS設定オプションを変える

kusanagi のssl関連設定のうち、HSTSのコマンドには4タイプの設定があります。

off : HSTS 無効。
weak: HSTS有効。指定したホスト名(FQDN)のサブドメインを含まない。
mid : HSTS有効。指定したホスト名(FQDN)のサブドメインを含む。プリロードHSTS使用しない。
high: HSTS有効。(指定したホスト名(FQDN)のサブドメインを含む。プリロードHSTSを使用する。

常時SSL化を効率的に行うためにHSTSは有効にしておきたいので、「off」の設定は選択肢にありませんでした。

また「high」のプリロードHSTSの使用についても考えていませんでした。こちらは「プリロード登録サイトに事前にホスト名を登録すると、プリロードが有効なブラウザは1回目のアクセスからhttpsを自動的に選択してくれる」というものです。外部サイトへの登録も必要というタイプのものです。

つまり「mid」か「weak」ということになりますが……。

セキュリティ上の設定が「weak」(弱)というと聞こえは悪いですが、そもそも当社運営サイトのドメインでもないわけですし、WordPressでサポート範囲は1サイトのみですからそれで必要十分だったのです。

【現在の手順】○

# kusanagi ssl --hsts weak プロファイル

ただ当時のサポートスタッフ側の共通手順は、ベースドメインやwww.ベースドメインだったらmid、それ以外のサブドメインならweakとなっていたのでした。

【当時の手順】×

( example.org、www.example.orgでのサイト運用の場合)
# kusanagi ssl --hsts mid プロファイル
(上記以外、campagin.example.orgなどのサブドメインで運用の場合)
# kusanagi ssl --hsts weak プロファイル

そもそも「mid」(中) で設定してしまうと、
[https://example.org](SSL)や[https://www.example.org](SSL)にアクセスする時は何の意識もせずにアクセスできますが、それ以外のサブドメインでSSL化されていないサイトへアクセスしようとするとするので、非SSLサイトなら、証明書エラーや、接続不可のエラーが出てしまうことになります。

別契約でご利用いただいていた共用サーバーは、メール関連にウェブメールツールや、メーリングリスト管理画面のURLも提供していたのですが、いずれも非SSLサイトでした。

ウェブメールツール:http://webmail.example.org (非SSL)
メーリングリスト管理画面:http://lists.example.org (非SSL)

「mid」(中)設定では、一度、[https://example.org](SSL)や[https://www.example.org](SSL)にアクセスしたことがあるブラウザから上記サイトにアクセスすると、ブラウザ+HSTSのお節介機能が働いてサブドメインサイトへのアクセスも[https://]が優先されるので、今まではなかった証明書エラーが現れるようになるのです。

なお「mid」「weak」について、実際にウェブサーバーのnginx上どういう設定になっていいるかというと

「mid」の場合
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains"; 
「weak」の場合
add_header Strict-Transport-Security "max-age=31536000"; 

というように記述に違いがあります。

今回のお客様については、ウェブサーバー側の設定変更を行ったことをご報告し、Google ChromeのHSTS設定(chrome://net-internals/#hsts)から、対象ドメインを削除する操作を行っていただいたうえで、再度これまでどおり、コントロールパネルのリンクからウェブメールへアクセスをお試しいただくようお願いしました。

ウェブブラウザーは、パソコンからスマートフォンにいたるまで、無料で配布されているソフトウェアなので見過ごしがちですが、最新のHTTP規格が常にアップデートされた結晶のような製品で、ウェブサーバーはウェブコンテンツ以外にもたくさんの情報を発信しつづけているのだなとあらためて思い知らされた出来事でした。

ピックアップフレーズ
必要十分な設定を目指すべき

セキュリティレベルを高くするといえば聞こえがよいが、利便性、可用性を鑑み、ちょうどいい塩梅を選択することが大事。

青影青影
HSTSの設定如何で、我々の知り得ないところでサイト表示に問題の出る可能性があるのですね。
ひとつのコマンド設定が及ぼす影響がはかりしれないものだと改めて実感しました。
シェア
赤影
赤影
生まれも育ちもこちらの事業部というサポートスタッフです。平素より筆ペンとGimpを愛用しています。
おすすめの記事