web-dev-qa-db-ja.com

IISを使用した同じサーバー上のSNIおよびワイルドカードSSL証明書

サブドメイン（sub.domain.comなど）をリッスンするWebサイトを、セカンドレベルドメイン（domain2.com、domain3.comなど）の直下にある複数のWebサイトと共にIISおよびSSLあり。

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

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

問題はまさにtitobfです ここで説明 ：理論的には、これにはSNIを使用するバインディングが必要です。domain2/ 3.comにホストを指定し、次に* Host for *を使用した包括的なWebサイトが必要です。 domain.com。しかし実際には、キャッチオール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ではありません。

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

最後にそれを基本的に機能させる

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バインディングが有効になりました。

iissslazuressl-certificatesni
12
Piedone

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

ワイルドカードフォールバック証明書には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());
        }
    }
}

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

working IIS configuration

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

6
Tobias J.

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

4
bariscaglar

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

http://www.vic.ms/Microsoft/windows-Azure/multiples-ssl-certificates-on-windows-Azure-cloud-services/

1
CamW