2018年10月31日まで延長されたOffice365のTLS1.2接続ですが、クライアントがTLS1.2を用いて接続しているかを確認するのは容易ではありません。
そこで、テストサイトを作成し、TLS1.2で接続できているか確認を行ってみましょう。
確認方法として、テスト用サーバーにIISを導入し、IISのログを確認するという方法をとりたいと思います。
2017年7月の更新となるKB4025334(Windows 10、Windows Server 2016),KB4025335(Windows Server 2012 R2)を導入しているとIIS 変数を通して、暗号化方式がわかるようになっていたようです。
【KB4025334の更新内容の一部】
まずはIISを準備しましょう。
サーバーマネージャーより役割と機能の追加を行います。(この例はWindows Server 2016です。流れはWindows Server 2012でも同じですが、細部が異なります。)
サーバー選択などを進めていきます。
IISの役割を与えるために「Web サーバ(IIS)」を選択します。
管理コンソールがあると便利なので、これも合わせて入れましょう。
選択が完了するとこんな感じに。
Windows 2012から役割がかなり細かく分かれているため、選択する機能については最低限となっていないかもしれませんが、私は「IIS ホスト可能なWebコア」にいつもチェックを入れています。
これは好みですが、PowerShell Web Applicationの機能をインストールしてみました。
細かな選択を省くためなので、これは全く必須ではありません。
この個別機能の導入がどちらかというと重要でして、、asp.netを動作させる土台はこれで完成です。
あとはそのまま設定を進めていくことでIIS構成は完了します。
再起動が嫌な場合はチェックを外しておきましょう。
ここまで完了すると、IISへアクセス可能となります。そういえば、ファイアウォールの設定を行わなかったのですが、最近はIIS設定すると解放されるようになったのでしょうか。これは簡単でありがたいですね。うまくつながらない場合はファイアウォールの設定は見直してみましょう。この時点ではPort80へのアクセスができるはずです。
続いて、IISマネージャを開きます。「Windows 管理ツール」の「インターネット インフォメーション サービス(IIS)マネージャー 」を起動します。
続いてログの設定を行います。この設定を行うことで、アクセスしてきた相手がどういった暗号化設定でやってきたかわかるようになります。
そのほか、HTTPS接続の設定を行います。
IISマネージャーのDefault Web Siteの設定を行っていきます。
ログ管理を開きます。
ログファイルの項が中央にあるので、フィールドの選択を押します。
W3Cのログフィールドが記載されていますが、ここにはないので、フィールドの追加を押してカスタムフィールドを追加しましょう。
追加となった項目は以下4種。それぞれ、ソースの種類を「サーバー変数」に設定し、「ソース」を以下の値で設定します。
CRYPT_PROTOCOL
CRYPT_CIPHER_ALG_ID
CRYPT_HASH_ALG_ID
CRYPT_KEYEXCHANGE_ALG_ID
こんな感じに追加していきます。
ここまで終わったらそのまま保存しましょう。
ログの設定はこれで完了です。ログの最後の4項目に暗号化情報が加わるようになりました。
続いてHTTPSの設定を行っておきます。自己証明の取得からHTTPSプロトコルの有効化を行います。
テスト環境限定ですが、自己サーバー証明書を発行します。外部につながる環境や、一時的な環境以外ではこの手順は厳禁です。
左ペインでサーバー選択して、右ペインでサーバー証明書を選択します。
右側のメニューに自己署名入り証明書の作成という項目があるので押します。
フレンドリ名を入力し、証明書ストアをWebホスティングにしてOKをおします。
フレンドリ名は通常DNSアドレス名となります。が、今回証明書は一致しない予定なので、何を入れても確認は可能です。
これで自己証明書が完成です。期限は1年で作成されるようですね。そしていつの間にかSHA256で作成されるようになったようです。Windows Server 2016だからでしょうか、、、
Default Web Siteに戻り、右側からバインドを選択します。
最初の段階ではポート80のみリスンするようになっているので、追加を押します。
種類をhttpsに変更します。
項目が増えるので、SSL証明書を未選択から先ほど作成した自己証明書に変更します。
こんな感じに選びます。
これでバインドも完成です。
あとはクライアントからアクセスしてみましょう。
自己証明のため、安全ではない旨が表示されます。
通常、自分が作ったサーバーでない場合は安全じゃないと表示されて当然なので、この後の作業を一般ユーザーに実施してもらう場合は、何をやっているか意識してやってもらいましょう。安全性にかかわることなので、意味が分からない人は下の手順は忘れてください。
https「https://serverName/」にアクセスすると、安全ではない旨が表示されます。以下はEdgeですが、詳細をクリックしてWebページへ移動(非推奨)を押してください。
URL欄に証明書エラーが表示されますが、サーバーへアクセスできました。
この状態でIISのログを閲覧してみましょう。(ログの場所はIISマネージャーのログ記録からわかります。)
以下はログの一部ですが、後ろ4項が暗号化方式となります。
この例では400から後ろの部分です。
このログ4項目のうち、先頭が400となっていればTLS1.2での接続となります。
ほかの数値であった場合は、Office365へ接続できなくなる可能性が高いため、クライアント側の設定を見直しましょう。
ちなみに、ログの設定を行わない場合は4項目が表示されません。
また、HTTPでのアクセス時は4項目とも「-」となるようです。
外部から接続状態をチェックするのは難しいですが、やっておかないと本当に接続できなくなった時に大変ですので、まずはブラウザから、チェックを行っていってみてください。
音楽:Jade