2013-07-05 41 views
15

Chúng tôi có một ứng dụng web chạy trên Dịch vụ đám mây Windows Azure tại ourapp.cloudapp.net. Chúng tôi đã tạo bản ghi CName từ my.ourapp.com để trỏ tới dịch vụ đám mây này. Miền này được bảo mật bằng SSL.Nhiều miền SSL cho một Trang web Dịch vụ Đám mây Azure

Bây giờ chúng ta có một yêu cầu để cho phép một tên miền khác nhau (my.secondapp.com) truy cập chính xác những gì được nhìn thấy trên my.ourapp.com.

Chúng tôi có thể tạo triển khai đám mây mới nhưng chúng tôi không muốn thêm chi phí để lưu trữ và duy trì triển khai riêng biệt. Chúng tôi cũng nghĩ về việc thêm một Điểm cuối https khác trên một cổng khác với 443 nhưng từ những gì tôi đã đọc, điều này có nghĩa là người dùng của chúng tôi sẽ phải điều hướng trang web của chúng tôi bằng hậu tố ": 444".

Sau khi thực hiện một số thao tác trên internet - chúng tôi đã xem qua bài viết này: http://www.vic.ms/microsoft/windows-azure/multiples-ssl-certificates-on-windows-azure-cloud-services/. Nó nói rằng việc sử dụng IIS8 và SNI chúng ta có thể có nhiều chứng chỉ cho một dịch vụ đám mây.

Tuy nhiên, chúng ta không thể có được điều này để làm việc - điều hướng đến my.secondapp.com đưa ra một cảnh báo chứng chỉ nói các CERT cung cấp là thực sự cho my.ourapp.com.

Dưới đây là một số gợi ý hơn:

  • Các cert cho cả my.ourapp.commy.secondapp.com dường như được cài đặt một cách chính xác (một thông qua thông thường Phương thức Azure và một thông qua mã SNI trong bài viết ở trên). Khi tôi từ xa vào vai trò web của chúng tôi và đi đến ISS - cả hai đều có mặt trong phần 'Server Cerificates'.

  • Không chắc chắn nếu điều này tạo ra sự khác biệt, nhưng tôi đọc nó trên một số bài viết trước đó: không có chứng chỉ trong phần "Web Hosting" trong MMC. Tôi đã thêm Snap-In cho Chứng chỉ theo cách thủ công và nhập chứng chỉ my.secondapp.com nhưng không có kết quả.

  • Trong IIS, chúng tôi có trang web vai trò web Azure thông thường trong máy chủ của chúng tôi - chẳng hạn như 'RD0001683008'. Khi tôi nhìn vào các tùy chọn Site Binding tôi thấy:

Loại|Tên máy chủ|Cổng|IP

http | (trống) | | 10.26.130.10

https | (trống) | | 10.26.130.10

https | my.secondapp.com | | 10.26.130.10

  • Tôi cố gắng để nhập my.ourapp.com vào phần hostname trong hai dòng đầu tiên hy vọng rằng nó sẽ chỉ nhặt hostname đó và không my.secondapp. com, nhưng không may mắn. Tôi đã thử thay đổi một địa chỉ IP thành 'All Unassigned' nhưng một lần nữa, không may mắn. Tôi có cần phải khởi động lại trang web hoặc hồ bơi ứng dụng không?

  • tôi loại bỏ các ràng buộc cho my.secondapp.com và thêm một trang web mới trong IIS với các chi tiết tương tự như my.ourapp.com (giống Application Pool và không gian web). Điều này đã cho tôi một dịch vụ 503 Unavailable đó là một cái gì đó khác nhau, nhưng tôi không chắc chắn nếu tôi nên tiếp tục khám phá tùy chọn này.

  • Một điều cần lưu ý khác là chứng chỉ SSL. Nó được tạo bởi bên thứ ba và hơi khác với số chứng nhận my.ourapp.com mà chúng tôi có. Thông thường, chúng tôi nhận được một tệp .crt và xuất tệp này thành tệp .pfx. Khi tôi cố gắng xuất chứng chỉ mới, các tùy chọn .pfx được tô xám và tôi chỉ có thể chọn .cer. Tôi đã làm một số phép thuật và quản lý để nhập khẩu và bằng cách nào đó xuất khẩu nó sang pfx, cung cấp một mật khẩu trên đường đi. Có lẽ bên thứ ba nên tạo cert với một mật khẩu trước đó trong quá trình này? Ngoài ra, bên thứ ba cung cấp ba certs (AddTrustExternalCARoot.crt, my_secondapp_com.crt, PositiveSSLCA2.crt). Tôi chỉ sử dụng my_secondapp_com.crt - tôi có nên sử dụng những người khác hoặc chuỗi chúng không?

  • Mở chính chứng chỉ rằng "Chứng chỉ này dành cho các mục đích sau:" và có thông thường "Đảm bảo danh tính của máy tính từ xa", "Chứng minh danh tính của bạn với máy tính từ xa". Nhưng cũng có hai dòng khác "1.3.6.1.4.1.6449.1.2.2.7" và "2.23.140.1.2.1" không có trên bất kỳ chứng chỉ nào khác mà chúng tôi có.

  • Cuối cùng, khi xem chứng chỉ trong phần Chứng chỉ trên cổng thông tin. Chủ đề cho chứng chỉ mới có "CN = my.secondapp.com, OU = PositiveSSL, OU = Được lưu trữ bởi Hosting Ireland, OU = Kiểm soát miền được xác thực" trong khi cert bình thường của chúng tôi có nhiều tùy chọn hơn: "CN = my.ourapp.com , OU = Kiểm soát miền được xác thực - RapidSSL (R), OU = Xem www.rapidssl.com/resources/cps (c) 11, OU = GT1234567, O = my.ourapp.com, C = IE, SERIALNUMBER = sOmESerIalNumBEr ". Điều này có thể có cái gì để làm với nó?

Xin lỗi vì câu hỏi dài - Tôi nghĩ là cung cấp càng nhiều chi tiết càng tốt có thể hữu ích.

Tôi thực sự đánh giá cao bất kỳ trợ giúp nào.

+0

Liên kết trang web bị hỏng. – Erik

+0

[Liên kết này] (http://blogs.msdn.com/b/jianwu/archive/2014/12/17/realize-ssl-service-for-multi-domains-in-the-same-cloud-service. aspx) có thể là một sự thay thế phù hợp nhưng tôi không chắc chắn vì tôi không thấy bản gốc. – Erik

Trả lời

12

Chỉ trong trường hợp một người nào đó nhu cầu khác giúp về vấn đề này, có hai vấn đề:

  1. Các SSL cert Tôi đã sử dụng không bị xiềng xích một cách chính xác.Nếu bạn nhận được 3 certs từ nhà cung cấp của bạn, bạn cần phải cài đặt chúng một cách chính xác bằng cách sử dụng IIS và MMC. Xem here để biết thêm thông tin.
  2. Bài viết SNI đã hoạt động. Vấn đề đối với chúng tôi là thứ tự ràng buộc. Chúng tôi đã kết thúc theo trình tự sau:

Website Bindings

Như bạn có thể thấy chúng tôi phải chơi xung quanh để có được điều này để làm việc nhưng các ràng buộc sau đây có nghĩa là cả hai lĩnh vực sẽ trỏ đến các ứng dụng web tương tự.

Bạn sẽ nhận thấy rằng chúng tôi đã thêm vào trong my.ourapp.com hai lần - một với SNI kích hoạt và một địa chỉ IP và người kia không. SNI không hoạt động với IE trên Windows XP - chúng tôi đã thêm tùy chọn cuối cùng làm liên kết mặc định, không phải SNI nên miền chính của chúng tôi sẽ luôn hoạt động, ngay cả trên IE & XP.

Hy vọng rằng sẽ giúp ai đó.

Các vấn đề liên quan