Google Chrome 80 になってから Cookie の扱いが変更になり、ついでに HTTPS ではないサイトへの風当たりが厳しくなりました。
今まではだましだまし使っていたサイトも、警告が出るようになりました。
これでも「詳細設定」を押してから"それでもつなぐボタン"でだまして使えていたのですが、CookieのSameSite問題の影響から、いよいよ重い腰を上げました。ちなみにHSTSサイトだと"それでもつなぐボタン"が出なくなります。
さて、IIS ローカル環境では、自己証明書を生成できるメニューがあります。自分のPCがルート証明機関の証明書を発行してくれるわけです。
しかし、これは機能不足で、開発環境ならではの複数ホストに対応できていません。複数ホストに対応するためには「*.jp」のワイルドカード証明書に対応するために、ホストヘッダの末尾を「.jp」にきれいにそろえてサイトを作るか、代替名でサイトを列記するしかありませんが、どちらも対応していません。以下の PS コマンドを、管理者権限で実行します。
New-SelfsignedCertificate -Subject "CN=CERT_ON_IIS" `
-DnsName "dev.example.jp", "dev.example.com", "dev.example.net" `
-Type "SSLServerAuthentication" `
-KeySpec "KeyExchange" `
-KeyUsage "DigitalSignature", "KeyEncipherment" `
-FriendlyName "IISの証明書です" `
-NotAfter $([datetime]::now.AddYears(1)) `
-CertStoreLocation cert:\localmachine\my
New-SelfsignedCertificate は自己証明を生成するコマンド。
-Subject はよくある証明書発行に必要な、一般名(CN)、組織(O)、部門(OU)、国(C)などの情報です。
-DnsName は証明書対応させるIISサイトをカンマ区切りで列記していきます。
-Type はサーバー認証ですよと指定します。もう固定値扱いです。
-KeySpec はキーの方式ですが、HTTPS 通信は鍵交換方式なので固定値。
-KeyUsage はキーを何に使うかですが、デジタル署名、暗号化といった、これもきっと固定値でしょう。
-FriendName は表示名です。わかりやすい名前にしましょう。
-NotAfter の以降は PS コマンドですが、1年間有効期間ですよと指定します。
-CertStoreLocation は生成された証明書の置き場所です。「個人」に格納されます。
これで、自己証明書は生成完了です。
今度は、スタートメニューで「証明書」と打ち込んで、生成されたものを確認しましょう。
生成された自己証明書が「個人」にあることを確認できたら、次はIISで使えるようにします。必要なのは「信頼されたルート証明機関」と「Web ホスティング」にコピーすることです。
さて「個人」にある証明書を「信頼されたルート証明機関」と「Web ホスティング」にコピーしましょう。Ctrlキーを押しながらマウスでぐいっと持って行けばコピーできます。ここでは「個人」を一時的な保管場所として使いました。両方にコピーした後は不要かつ混乱の元になるので削除しましょう。
いよいよ最後の手順です。IISに証明書を認識してもらいます。先に述べたように、IISでは複数ホストを登録できます。HTTPの80ポートどうしでバインドしていてもホストヘッダで識別できましたが、HTTPSの443ポートで受け付けられる証明書はひとつだけです。このひとつの証明書を使って復号化してからホストヘッダの判定に入るわけなので、複数登録できないのもわかります。