Sertifikat SNI dan wildcard SSL pada server yang sama dengan IIS


12

Saya ingin meng-host situs web yang harus mendengarkan subdomain (mis., Subdomain.com) bersama dengan beberapa situs web yang hidup tepat di bawah domain tingkat kedua (mis. Domain2.com, domain3.com) dengan IIS dan dengan SSL.

Untuk situs web dengan subdomain saya memiliki sertifikat wildcard (* .domain.com) dan saya juga memiliki sertifikat khusus untuk situs lain (domain2.com dan domain3.com).

Bisakah pengaturan seperti itu di-host pada IIS yang sama (jika itu penting, dalam peran web Layanan Cloud Azure)?

Masalahnya persis dengan apa yang dijelaskan titobf di sini : secara teoritis untuk ini kita akan memerlukan binding menggunakan SNI, dengan host yang ditentukan untuk domain2 / 3.com dan kemudian situs web untuk semua domain dengan * host untuk * .domain.com. Namun dalam praktiknya, tidak peduli bagaimana ikatannya dipasang jika situs web catch-all ada di dalamnya, juga akan menerima semua permintaan ke domain2 / 3.com (meskipun seharusnya hanya cocok sebagai pilihan terakhir).

Bantuan apa pun akan dihargai.

Masih belum terpecahkan

Sayangnya saya tidak dapat menyelesaikan ini: tampaknya hanya dapat dipecahkan dengan cara yang sangat rumit, seperti membuat perangkat lunak yang terletak antara IIS dan internet (jadi pada dasarnya firewall) dan memodifikasi permintaan yang masuk (sebelum jabat tangan SSL terjadi! ) untuk memungkinkan skenario. Saya cukup yakin ini tidak mungkin dengan IIS, tidak peduli apa, bahkan dari modul asli.

Saya harus mengklarifikasi: kami menggunakan Azure Cloud Services, jadi kami memiliki batasan lebih lanjut bahwa kami tidak dapat menggunakan beberapa alamat IP (lihat: http://feedback.azure.com/forums/169386-cloud-services-web-and -pekerja-peran / saran / 1259311-multi-ssl-dan-domain-ke-satu-aplikasi ). Jika Anda dapat mengarahkan beberapa IP ke server Anda, maka Anda tidak memiliki masalah ini karena Anda juga dapat membuat binding untuk IP, dan itu akan bekerja sama binding wildcard. Lebih khusus lagi, Anda memerlukan IP untuk situs wildcard (tetapi karena Anda memiliki IP terpisah sekarang Anda tidak perlu mengkonfigurasi mengikat nama host wildcard) dan IP lain untuk semua yang non-wildcard.

Sebenarnya solusi kami adalah penggunaan port SSL non-standar, 8443. Jadi mengikat SNI sebenarnya terikat ke port ini, sehingga bekerja bersama dengan binding lainnya. Tidak bagus, tetapi solusi yang dapat diterima bagi kami sampai Anda dapat menggunakan beberapa IP untuk peran web.

Binding tidak bekerja sekarang

Ikatan https pertama adalah SNI dengan sertifikat sederhana, yang kedua bukan SNI, dengan sertifikat wildcard.

Situs http berfungsi, serta situs https SNI, tetapi situs yang mengikat wildcard memberikan "Kesalahan HTTP 503. Layanan tidak tersedia." (tanpa informasi lebih lanjut, tidak ada Pelacakan Permintaan Gagal atau entri Log Kejadian). Binding

Akhirnya membuatnya pada dasarnya bekerja

Mengaktifkan log jejak ETW seperti yang dijelaskan Tobias menunjukkan bahwa kesalahan root adalah sebagai berikut:

Permintaan (ID permintaan 0xF500000080000008) ditolak karena alasan: UrlGroupLookupFailed.

Sejauh yang saya mengerti ini berarti http.sys tidak dapat merutekan permintaan ke titik akhir yang tersedia.

Memeriksa titik akhir yang terdaftar dengan netsh http show urlaclmenunjukkan bahwa memang ada sesuatu yang terdaftar untuk port 443:

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

Menghapus ini dengan netsh http delete urlacl url=https://IP:443/akhirnya mengaktifkan ikatan SSL saya.


Anda harus benar-benar dapat melakukan ini pada IIS menggunakan SNI, tanpa menggunakan beberapa IP atau port non-standar.
Joe Sniderman

Maksud Anda IIS harus mendukung ini? Saya setuju :-).
Piedone

Saya sangat setuju dengan Anda, Piedone. Saya benar-benar kecewa bahwa IIS (atau lebih tepatnya http.sys) TIDAK mendukung kombinasi sertifikat wildcard sebagai sertifikat SSL default dan beberapa sertifikat konkret dengan SNI SEPERTI YANG DIHARAPKAN. Masalahnya sudah diketahui sejak 2012 seperti yang Anda lihat di sini: forums.iis.net/t/1192170.aspx . Saya baru saja menulis email ke Microsoft dan berharap untuk mendapatkan umpan balik segera.
Tobias J.

Terima kasih Tobias Silakan kembali ke sini setelah Microsoft menjawab.
Piedone

2
Mungkin http.sys menolak permintaan tersebut sehingga tidak ada Permintaan Gagal yang masuk ke IIS. Buat http.sys ETW trace log: 1) mulai log penelusuran. jalankan: logman start httptrace -p Microsoft-Windows-HttpService 0xFFFF -o httptrace.etl -ets2) lakukan permintaan 503 3) hentikan jejak log. jalankan: logman stop httptrace -ets4) tulis log jejak ke file. jalankan: tracerpt.exe httptrace.etl -of XML -o httptrace.xml5) periksa alasan 503 dalam file xml dan posting di sini.
Tobias J.

Jawaban:


6

Baris benar! Sertifikat SSL yang dikonfigurasi pada IP: PORT binding (contoh: 100.74.156.187:443) selalu didahulukan di http.sys! Jadi solusinya adalah sebagai berikut:

Jangan konfigurasikan IP: 443 yang mengikat untuk wildcard-fallback-sertifikat Anda, tetapi konfigurasikan ikatan *: 443 (* berarti "Semua Tidak Ditugaskan") untuk itu .

Jika Anda telah mengonfigurasi sertifikat wildcard Anda pada titik akhir SSL Layanan Azure Cloud (seperti yang saya miliki), Anda harus mengubah pengikatan SSL yang dibuat oleh Azure Cloud Service Runtime (IISconfigurator.exe) dari IP: PORT ke *: PORT. Saya memanggil metode berikut di OnStart peran web saya:

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

Tangkapan layar berikut menunjukkan konfigurasi yang berfungsi dari layanan cloud kami. Tolong jangan bingung tentang port non-standar. Tangkapan layar berasal dari layanan cloud yang ditiru.

bekerja konfigurasi IIS

Satu hal lagi yang perlu disebutkan: Jangan mengubah semua binding ke * karena mengikat HTTP (port 80) hanya berfungsi dengan IP: PORT mengikat dalam layanan cloud yang digunakan. Sesuatu yang lain terikat ke IP: 80 sehingga *: 80 tidak berfungsi karena * adalah singkatan dari "all unassigned" dan IP sudah ditugaskan di tempat lain di http.sys.


Terima kasih atas jawaban terinci Anda. Saya memperbarui pertanyaan saya: karena saya ingat sekarang saya mungkin tidak pergi dengan pengaturan ini karena saya mendapatkan kesalahan yang sama seperti sekarang.
Piedone

4

Pastikan pengikat semua tangkapan Anda tidak dari tipe IP: Port. Ketika IP: Port binding ada untuk HTTPS mengikat sementara SNI tidak diperlukan, mengikat itu akan selalu diutamakan. Untuk case catch-all Anda, gunakan *: Port binding (* menjadi semua yang belum ditetapkan).


Terima kasih, tetapi seperti yang dapat Anda lihat dalam uraian saya, saya awalnya mencoba mengatur penjilidan SNI tanpa port, tetapi karena itu tidak berhasil saya berakhir dengan port binding khusus.
Piedone

Dengan port, saya menganggap Anda maksud IP. Anda tidak dapat memiliki ikatan tanpa porta. Inetmgr tidak akan mengizinkannya. Untuk binding SNI Anda dapat menggunakan IP spesifik atau "Semua Tidak Ditugaskan" dan hasilnya akan sama. Ini adalah ikatan Catch All, yang untuknya Anda memiliki sertifikat wildcard, yang harus menggunakan "Semua Tidak Ditugaskan" dan bukan pada IP tertentu.
bariscaglar

Maksud saya port tetapi saya ingin mengatakan "port non-standar". IP tidak ditentukan, seperti yang Anda katakan dan masih tidak berfungsi, lihat juga tautan Tobias. Ada dua cara untuk mengatasi batasan IIS ini: gunakan port khusus atau IP yang berbeda dari binding lainnya: pada layanan cloud Azure yang terakhir tidak tersedia sehingga kami menggunakan port khusus.
Piedone

bariscaglar adalah pengembang Microsoft (bekerja pada IIS) saya memiliki percakapan yang sangat bagus dan bermanfaat dengan! Thx Baris! Bersama-sama kami menganalisis perilaku dan kami sampai pada kesimpulan, bahwa perilaku yang dijelaskan adalah perilaku yang diinginkan dari http.sys. Tapi ada solusi yang bagus. Lihat jawaban saya untuk detailnya.
Tobias J.

Sebagai catatan bagi siapa saja yang membaca, saya baru-baru ini menemukan bahwa jika Anda menggunakan Azure Portal untuk mengkonfigurasi layanan untuk Remote Desktop (atau mengubah konfigurasi cert) dapat menyebabkan IP: Port binding dibuat secara otomatis dan menghancurkan semua SNI Anda . Saya tidak punya solusi untuk masalah khusus itu. Itu terjadi setelah RoleEnvironment.Changed jadi saya tidak bisa menangkapnya di WebRole.cs.
Mike

1

IIS mendukung SNI, bahkan dalam peran web layanan cloud biru meskipun Anda tidak bisa mengakses konfigurasi melalui portal dan jika Anda melakukannya di kotak setelah penyebaran, itu akan dihapus dengan penyebaran Anda berikutnya. Solusinya adalah mengotomatisasi konfigurasi. Lihat detailnya di sini:

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


Terima kasih, tetapi seperti yang saya jelaskan, tidak ada masalah dengan SNI itu sendiri (saya menggunakannya) melainkan bagaimana cara pencocokan nama host wildcard bekerja di IIS.
Piedone

Artikel ini tidak ada lagi, tetapi di sini ada di Web Archive: web.archive.org/web/20151020041907/http://www.vic.ms/microsoft/…
Mike
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.