IIS가있는 동일한 서버의 SNI 및 와일드 카드 SSL 인증서

IIS 및 SSL을 사용하여 두 번째 수준 도메인 (예 : domain2.com, domain3.com) 바로 아래에있는 여러 웹 사이트와 함께 하위 도메인 (예 : sub.domain.com)을 수신해야하는 웹 사이트를 호스팅하고 싶습니다.

하위 도메인이있는 웹 사이트의 경우 와일드 카드 인증서 (* .domain.com)가 있으며 다른 사이트 (domain2.com 및 domain3.com)에 대한 인증서도 있습니다.

이러한 설정을 동일한 IIS에서 호스팅 할 수 있습니까 (필요한 경우 Azure 클라우드 서비스 웹 역할)?

문제는 여기에서 titobf가 정확히 설명한 것입니다 . 이론적으로이를 위해서는 SNI를 사용하여 domain2 / 3.com에 지정된 호스트와 * .domain.com에 대한 * host가있는 포괄 웹 사이트를 사용하여 바인딩해야합니다. 그러나 실제로 모든 웹 사이트가있는 경우 바인딩 설정 방법에 관계없이 domain2 / 3.com에 대한 모든 요청도 수신합니다 (마지막 수단으로 만 일치한다고 가정).

도움을 주시면 감사하겠습니다.

여전히 해결되지 않은

불행히도이 문제를 해결할 수 없었습니다 .IIS와 인터넷 (기본적으로 방화벽) 사이에있는 소프트웨어를 만들고 들어오는 요청을 수정하는 것과 같은 매우 복잡한 방법으로 만 해결할 수있는 것처럼 보입니다 (SSL 핸드 셰이크가 발생하기 전에)! )를 사용하여 시나리오를 허용합니다. 나는 이것이 네이티브 모듈조차 아니더라도 IIS로는 불가능하다고 확신합니다.

명확히해야합니다 : 우리는 Azure Cloud 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의 경우 다른 IP가 필요합니다.

실제로 우리의 해결 방법은 비표준 SSL 포트 인 8443을 사용하는 것이 었습니다. 따라서 SNI 바인딩은 실제로이 포트에 바인딩되므로 다른 바인딩과 함께 작동합니다. 웹 역할에 여러 개의 IP를 사용할 수있을 때까지는 좋지 않지만 해결 가능한 해결책입니다.

작동하지 않는 바인딩

첫 번째 https 바인딩은 간단한 인증서를 사용하는 SNI이고 두 번째는 와일드 카드 인증서를 사용하는 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에서 우선합니다! 따라서 해결책은 다음과 같습니다.

와일드 카드 대체 인증을 위해 IP : 443 바인딩을 구성하지 말고 * : 443 바인딩을 구성하십시오 (*는 "모든 할당되지 않음"을 의미 함) .

Azure 클라우드 서비스 SSL 끝점에서 와일드 카드 인증서를 구성한 경우 (있는 그대로) Azure 클라우드 서비스 런타임 (IISconfigurator.exe)에서 만든 SSL 바인딩을 IP : PORT에서 * : PORT로 변경해야합니다. 내 웹 역할의 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의 다른 곳에 이미 할당되어 있기 때문입니다.

catch-all 바인딩이 IP : Port 유형이 아닌지 확인하십시오. SNI가 필요하지 않은 상태에서 HTTPS 바인딩에 대해 IP : Port 바인딩이 존재하면 해당 바인딩이 항상 우선합니다. 포괄적 인 경우에는 * : Port 바인딩을 사용하십시오 (*는 모두 할당되지 않음).

IIS는 Azure 클라우드 서비스 웹 역할에서도 SNI를 지원하지만 포털을 통해 구성에 도달 할 수는 없지만 배치 후 즉시 구성을 수행하면 다음 배치에서 삭제됩니다. 해결책은 구성을 자동화하는 것입니다. 자세한 내용은 여기를보십시오 :

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