IISと同じサーバー上のSNIおよびワイルドカードSSL証明書

サブドメイン（sub.domain.comなど）をリッスンするWebサイトを、IISおよびSSLを使用して、第2レベルドメイン（domain2.com、domain3.comなど）の直下に存在する複数のWebサイトと共にホストしたいと思います。

サブドメインを含むWebサイトには、ワイルドカード証明書（* .domain.com）があり、他のサイト（domain2.comおよびdomain3.com）専用の証明書もあります。

そのようなセットアップは、同じIISでホストできますか（もしそれが重要な場合、Azure Cloud Service Webロールで）？

問題は、ここで titobfが説明したとおりです。理論的には、SNIを使用してバインドし、domain2 / 3.comにホストを指定し、次に* .domain.comに*ホストを使用したキャッチオールWebサイトを使用する必要があります。ただし、実際には、キャッチオールWebサイトが有効になっている場合、バインディングの設定方法に関係なく、domain2 / 3.comへのすべての要求も受信します（ただし、最後の手段としてのみ一致するはずです）。

任意の助けをいただければ幸いです。

未解決

残念ながら、これを解決することはできませんでした。IISとインターネット（基本的にはファイアウォール）の間に位置し、SSLハンドシェイクが行われる前に着信要求を変更するソフトウェアを作成するなど、非常に複雑な方法でしか解決できないようです！ ）シナリオを許可します。これは、IISでは不可能であり、ネイティブモジュールからでさえ不可能だと確信しています。

明確にする必要があります。AzureCloud Servicesを使用しているため、複数のIPアドレスを使用できないという制約があります（http://feedback.azure.com/forums/169386-cloud-services-web-and -worker-role / suggestions / 1259311-multiple-ssl-and-domains-to-one-app）。複数のIPをサーバーに向けることができる場合、IPのバインディングも作成できるため、この問題はありません。これらは一緒にワイルドカードバインディングで機能します。具体的には、ワイルドカードサイト用のIP（ただし、別のIPを使用しているため、ワイルドカードホスト名バインディングを構成する必要はありません）および他のすべての非ワイルドカード用のIPが必要です。

実際の回避策は、非標準SSLポート8443の使用でした。したがって、SNIバインディングは実際にこのポートにバインドされているため、他のバインディングと一緒に機能します。いいとは言えませんが、Webロールに複数のIPを使用できるようになるまでは、回避策として受け入れられます。

動作しないバインディング

最初のhttpsバインディングは単純な証明書を使用したSNIであり、2番目はワイルドカード証明書を使用したSNIではありません。

SNI httpsサイトと同様にhttpサイトも機能しますが、ワイルドカードバインディングを使用したサイトでは「HTTPエラー503。サービスは利用できません」と表示されます。（追加情報なし、失敗した要求トレースまたはイベントログエントリなし）。

最後に基本的に動作させる

説明したTobiasのようなETWトレースログを有効にすると、ルートエラーは次のようになりました。

要求（要求ID 0xF500000080000008）は理由により拒否されました：UrlGroupLookupFailed。

私が理解している限り、これはhttp.sysが利用可能なエンドポイントにリクエストをルーティングできないことを意味します。

登録されたエンドポイントをチェックすると、netsh http show urlacl実際にポート443に何かが登録されていることがわかりました。

Reserved URL            : https://IP:443/
    User: NT AUTHORITY\NETWORK SERVICE
        Listen: Yes
        Delegate: No
        SDDL: D:(A;;GX;;;NS)

これでnetsh http delete urlacl url=https://IP:443/最終的に削除すると、SSLバインディングが有効になりました。

バリスは正しい！IP：PORTバインディングで構成されたSSL証明書（例：100.74.156.187:443）は、http.sysで常に優先されます！したがって、解決策は次のとおりです。

wildcard-fallback-certificateにIP：443バインディングを構成しないでください。ただし、*：443バインディング（*は「すべて未割り当て」を意味します）を構成します。

Azure Cloud Service SSLエンドポイントでワイルドカード証明書を構成した場合（私が持っているように）、Azure Cloud Service Runtime（IISconfigurator.exe）によって作成されたSSLバインディングをIP：PORTから*：PORTに変更する必要があります。WebロールのOnStartで次のメソッドを呼び出しています。

public static void UnbindDefaultSslBindingFromIp()
{
    Trace.TraceInformation(">> IISTenantManager: Unbind default SSL binding from IP");
    using (var serverManager = new Microsoft.Web.Administration.ServerManager())
    {
        try
        {
            var websiteName = string.Format("{0}_Web", Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.CurrentRoleInstance.Id);
            var site = serverManager.Sites[websiteName];
            var defaultSslBinding = site.Bindings.Single(b => b.IsIPPortHostBinding && b.Protocol == "https");
            defaultSslBinding.BindingInformation = string.Format("*:{0}:", defaultSslBinding.EndPoint.Port);
            serverManager.CommitChanges();
        }
        catch (Exception ex)
        {
            Trace.TraceError(ex.ToString());
        }
    }
}

次のスクリーンショットは、クラウドサービスの動作構成を示しています。非標準ポートについて混同しないでください。スクリーンショットは、エミュレートされたクラウドサービスのものです。

さらに言及すべきこと：すべてのバインディングを*に変更しないでください。HTTP（ポート80）バインディングは、デプロイされたクラウドサービスのIP：PORTバインディングでのみ機能するためです。他のものはIP：80にバインドされているため、*：80は機能しません。*は「すべて未割り当て」を表し、IPはhttp.sysの別の場所に既に割り当てられているためです。

キャッチオールバインディングのタイプがIP：Portでないことを確認してください。HTTPSバインディングにIP：Portバインディングが存在し、SNIが不要な場合、そのバインディングが常に優先されます。キャッチオールの場合、*：Portバインディングを使用します（*はすべて未割り当てです）。

IISはazureクラウドサービスのWebロールでもSNIをサポートしますが、ポータルから構成にアクセスすることはできません。また、展開後にボックスで行うと、次の展開で消去されます。解決策は、構成を自動化することです。詳細はこちらをご覧ください：

http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certificates-on-windows-azure-cloud-services/