Chứng chỉ SSL SNI và ký tự đại diện trên cùng một máy chủ với IIS

Tôi muốn lưu trữ một trang web nên lắng nghe các tên miền phụ (ví dụ: sub.domain.com) cùng với nhiều trang web sống dưới một tên miền cấp hai (ví dụ: domain2.com, domain3.com) với IIS và với SSL.

Đối với trang web có tên miền phụ, tôi có chứng chỉ ký tự đại diện (* .domain.com) và tôi cũng có chứng chỉ dành riêng cho các trang web khác (domain2.com và domain3.com).

Thiết lập như vậy có thể được lưu trữ trên cùng một IIS (nếu có vấn đề, trong vai trò web của Azure Cloud Service)?

Vấn đề chính xác là những gì Titobf đã giải thích ở đây : về mặt lý thuyết, chúng tôi cần các ràng buộc bằng SNI, với máy chủ được chỉ định cho domain2 / 3.com và sau đó là một trang web bắt tất cả với * host cho * .domain.com. Nhưng trong thực tế, bất kể các ràng buộc được thiết lập như thế nào nếu trang web bắt tất cả cũng sẽ nhận được tất cả các yêu cầu đến domain2 / 3.com (mặc dù được cho là chỉ phù hợp như là phương sách cuối cùng).

Bất kỳ trợ giúp sẽ được đánh giá cao.

Vẫn chưa giải quyết

Thật không may, tôi không thể giải quyết vấn đề này: dường như chỉ có thể giải quyết được bằng những cách cực kỳ phức tạp, như tạo một phần mềm nằm giữa IIS và internet (về cơ bản là tường lửa) và sửa đổi các yêu cầu đến (trước khi bắt tay SSL! ) để cho phép kịch bản. Tôi khá tự tin rằng điều này là không thể với IIS, bất kể là gì, thậm chí từ mô-đun gốc.

Tôi phải làm rõ: chúng tôi sử dụng Azure Cloud Services, vì vậy chúng tôi có một hạn chế hơn nữa là chúng tôi không thể sử dụng nhiều địa chỉ IP (xem: http://feedback.azure.com/forums/169386-cloud-service-web-and -worker-vai trò / đề xuất / 1259311-nhiều-ssl-và-domain-to-one-app ). Nếu bạn có thể trỏ nhiều IP đến máy chủ của mình thì bạn không gặp phải vấn đề này vì bạn cũng có thể tạo các ràng buộc cho IP và chúng sẽ hoạt động cùng với các ràng buộc ký tự đại diện. Cụ thể hơn, bạn cần một IP cho trang web ký tự đại diện (nhưng vì giờ bạn đã có một IP riêng nên bạn sẽ không phải định cấu hình ràng buộc tên máy chủ ký tự đại diện) và một IP khác cho tất cả các trang không phải ký tự đại diện khác.

Trên thực tế, cách giải quyết của chúng tôi là việc sử dụng cổng SSL không chuẩn, 8443. Vì vậy, ràng buộc SNI thực sự bị ràng buộc với cổng này, do đó nó hoạt động cùng với các ràng buộc khác. Không đẹp, nhưng một cách giải quyết có thể chấp nhận được đối với chúng tôi cho đến khi bạn có thể sử dụng nhiều IP cho các vai trò web.

Các ràng buộc không làm việc bây giờ

Liên kết https đầu tiên là SNI với chứng chỉ đơn giản, thứ hai không phải là SNI, với chứng chỉ ký tự đại diện.

Trang web http hoạt động, cũng như trang web SNI https, nhưng trang web có ràng buộc ký tự đại diện cho "Lỗi HTTP 503. Dịch vụ không khả dụng." (không có thêm thông tin, không có mục Yêu cầu theo dõi hoặc Nhật ký sự kiện không thành công).

Cuối cùng, làm cho nó cơ bản hoạt động

Kích hoạt nhật ký theo dõi ETW như Tobias mô tả cho thấy lỗi gốc là như sau:

Yêu cầu (ID yêu cầu 0xF500000080000008) bị từ chối vì lý do: UrlgroupLookupFails.

Theo tôi hiểu điều này có nghĩa là http.sys không thể định tuyến yêu cầu đến bất kỳ điểm cuối có sẵn nào.

Kiểm tra các điểm cuối đã đăng ký netsh http show urlaclcho thấy thực sự đã có thứ gì đó được đăng ký cho cổng 443:

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

Loại bỏ điều này netsh http delete urlacl url=https://IP:443/cuối cùng đã kích hoạt ràng buộc SSL của tôi.

Baris nói đúng! Chứng chỉ SSL được định cấu hình trên ràng buộc IP: PORT (ví dụ: 100.74.156.187:443) luôn được ưu tiên trong http.sys! Vì vậy, giải pháp như sau:

Không định cấu hình ràng buộc IP: 443 cho chứng chỉ ký tự đại diện của bạn nhưng cấu hình ràng buộc *: 443 (* có nghĩa là "Tất cả chưa được gán") cho nó .

Nếu bạn đã định cấu hình chứng chỉ ký tự đại diện của mình trên điểm cuối SSL của Dịch vụ đám mây Azure (như tôi có), bạn phải thay đổi liên kết SSL được tạo bởi Thời gian chạy dịch vụ đám mây Azure (IISconfigurator.exe) từ IP: PORT thành *: PORT. Tôi đang gọi phương thức sau trong OnStart về vai trò web của mình:

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());
        }
    }
}

Ảnh chụp màn hình sau đây cho thấy cấu hình hoạt động của dịch vụ đám mây của chúng tôi. Xin đừng nhầm lẫn về các cổng không chuẩn. Ảnh chụp màn hình là từ dịch vụ đám mây giả lập.

Một điều nữa cần đề cập: Không thay đổi tất cả các ràng buộc thành * vì liên kết HTTP (cổng 80) chỉ hoạt động với ràng buộc IP: PORT trong dịch vụ đám mây được triển khai. Một cái gì đó khác được liên kết với IP: 80 vì vậy *: 80 không hoạt động vì * là viết tắt của "tất cả chưa được gán" và IP đã được gán ở một nơi khác trong http.sys.

Đảm bảo rằng ràng buộc bắt tất cả của bạn không phải là loại IP: Cổng. Khi IP: Liên kết cổng tồn tại đối với liên kết HTTPS trong khi SNI không bắt buộc, ràng buộc đó sẽ luôn được ưu tiên. Đối với trường hợp bắt tất cả của bạn, hãy sử dụng ràng buộc *: Cổng (* là tất cả chưa được gán).

IIS không hỗ trợ SNI, ngay cả trong các vai trò web của dịch vụ đám mây màu xanh lam mặc dù bạn không thể truy cập cấu hình qua cổng và nếu bạn thực hiện trên hộp sau khi triển khai, nó sẽ bị xóa bằng triển khai tiếp theo của bạn. Giải pháp là tự động hóa cấu hình. Có một cái nhìn ở đây để biết chi tiết:

http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certert-on-windows-azure-cloud-service/