IIS8.5でのSSL-名前付きURLを処理しますが、ローカルホストはERR_CERT_COMMON_NAME_INVALIDになります
Win Server 2K12R2でIIS8.5を実行しています。サーバーの名前foo.domain.comに有効なSSL証明書を登録しています。
この証明書でhttpsを使用するようにWebサイトのバインディングを構成しました。
https://foo.domain.comと話すと、Webサイトと正常に会話できますが、https://localhost.comまたはhttps://127.0.0.1を使用すると、正常に会話できません。
Localhostを介して正常に通信できるようにするには、何をする必要がありますか？
私が試してみました：
- 自己署名証明書を作成して使用しようとしましたが、同じWebサイトに2つの証明書を使用することはできません。ローカルホストに自己署名を使用すると、
foo.domain.comを介して通信する機能が無効になります
していません：
mmc.exe certmgr.mscを使用して手動で中間COMODO証明書を適用しようとしました。私の現在のセットアップは外部で動作しているので、これは問題ではないと思います。- ローカルホストを
foo.domain.comにリダイレクトするようにhostsファイルを変更しました
SSL証明書は、受信者がWebサイトにアクセスするための正確なFQDNに対してのみ有効です。 SSL証明書の件名と、URLアドレスバーのサーバーFQDNが一致している必要があります。たとえば、それは有効ですのみfoo.domain.comではなく、fooではなく、localhostではなく127.0.0.1ではありません。これは仕様によるものです。これがSSL証明書のしくみです。
理論的には無限の数の「localhost」が存在し、実際にIDを検証する方法がないため、自尊心のある認証局が「localhost」のSSL証明書を発行することはありません。
他の人が述べているように、SSL証明書は使用されている正確なFQDNに対してのみ有効です。 IISで自己署名証明書を作成すると、「発行先」の名前が提供されます。 「localhost」の代わりにこれを使用すると、証明書が機能するはずです。たとえば、マシンの名前がfoo.bar.comの場合、URLでhttps://foo.bar.comの代わりにhttps://localhostを使用できます。
私の場合、名前で解決できるDNSサーバーがなかったため、IPでリモート開発サーバーにアクセスしていました。私はあなたが受け取ったエラーを受け取り続けました。私の場合、マシン名はfoo.bar.localのようなもので、IPアドレスは10.1.1.37のようなものでした。 IIS自己署名証明書を作成すると、それがfoo.bar.localに発行されました。そのため、これを機能させるために、クライアントマシンのhostsファイル（c：\ windows）にエントリを追加しました。\system32\drivers\ets\hosts）foo.bar.localを10.1.1.37にポイントし、https://foo.bar.localの代わりにhttps://10.1.1.37の使用を開始しました。それ以降は動作を開始しました。
もちろん、これはすべて、クライアントマシンの信頼されたルート証明機関に証明書がすでにインストールされていることを前提としています。
お役に立てば幸いです。