Mengapa Window's SSL Cipher-Suite dibatasi di bawah sertifikat SSL tertentu?


14

Masalah: Windows Server 2008 R2 hanya akan mendukung suite sandi ssl berikut ketika menggunakan sertifikat tertentu di server:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

Ini mencegah klien XP dari terhubung ke server karena XP Cryptographic API tidak mendukung cipher AES secara default.
Akibatnya, kesalahan berikut muncul di log server ketika mencoba untuk terhubung menggunakan internet explorer atau desktop jarak jauh. (Karena mereka menggunakan CAPI microsoft)

Schannel Error 36874 "Sambungan TLS 1.0 telah diterima dari aplikasi klien jarak jauh, tetapi dodne dari suite sandi yang didukung oleh klien didukung oleh server. Permintaan koneksi SSL telah gagal."
Schannel Error 36888 "Peringatan fatal berikut ini dihasilkan: 40. Status kesalahan internal adalah 1204"


2
Gary, jika Anda memecahkan pertanyaan Anda sendiri, harap tandai sebagai dijawab.
Bernie White

Jawaban:


14

Jika sertifikat yang digunakan di server dibuat menggunakan opsi Legacy Key dalam formulir permintaan sertifikat, kunci pribadi untuk sertifikat itu akan disimpan dalam kerangka API Cryptographic legacy Microsoft. Ketika server web mencoba memproses permintaan menggunakan kerangka kerja baru, Cryptographic Next Generation (CNG), tampaknya ada sesuatu yang terkait dengan kunci pribadi RSA yang disimpan dalam kerangka kerja warisan tidak tersedia untuk kerangka kerja baru. Akibatnya, penggunaan cipher suites RSA sangat terbatas.

Solusi:
Buat permintaan sertifikat menggunakan templat Kunci CNG di panduan permintaan sertifikat khusus.

MMC | Manajer Sertifikat Komputer Lokal | Folder Sertifikat Pribadi | (klik kanan) | Semua Tugas -> Operasi Lanjut | Buat Permintaan Kustom | "Lanjutkan tanpa kebijakan pendaftaran" | pilih "(tanpa templat) kunci CNG" | lanjutkan untuk menyelesaikan permintaan sertifikat sesuai dengan kebutuhan Anda.

Memverifikasi bahwa kuncinya ada di tempat yang tepat:
http://msdn.microsoft.com/en-us/library/bb204778(VS.85).aspx
http://www.jensign.com/KeyPal/index.html

Alat untuk memverifikasi cipher-suites yang benar:
http://pentestit.com/2010/05/16/ssltls-audit-audit-web-servers-ssl-ciphers/
https://www.ssllabs.com/

Pengaturan cipher-suite SSL:
http://support.microsoft.com/kb/245030
http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order -in-internet-explorer-7-di-windows-vista.aspx

Kami membutuhkan waktu seminggu untuk mencari tahu. Saya harap ini menyelamatkan seseorang dari masalah yang sama.


Adakah yang tahu bagaimana melakukan ini - atau menyelesaikan masalah - untuk sertifikat yang ditandatangani sendiri?
MGOwen

Terima kasih banyak Gerry untuk pekerjaan Anda dan membagikan hasil Anda! Kami membuka Microsoft Support Case dan Microsoft sendiri tidak dapat mengetahui mengapa klien tertentu tidak dapat terhubung. Kami telah memiliki Masalah persis seperti yang Anda jelaskan. Tetapi menurut technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx Microsoft sendiri merekomendasikan penggunaan Legacy Key Template untuk mengarsip kompatibilitas terbaik! Kerja bagus!

2

Mendapat masalah yang sama persis ini sendiri dan pos ini menghemat banyak waktu, jadi terima kasih semuanya!

Solusi Gary sudah tepat tetapi saya berhasil menyelesaikan masalah hanya dengan mengubah PFX menjadi PEM dan kemudian kembali ke PFX lagi menggunakan openssl. PFX baru mengimpor sertifikat di IIS sama dengan perbedaan bahwa saya bisa melihat cipher yang hilang.

Begini caranya:

openssl pkcs12 -in mycert.pfx -out mycert.cer -nodes

Kemudian bagi file cer menjadi tiga, kunci, sertifikat dan sertifikat antara [s]

openssl pkcs12 -export -out mycert-new.pfx -inkey mycert.key \
-in mycert.crt -certfile mycert-intermediate.crt

Kemudian jika Anda mengimpor file .pfx baru ke IIS, ia akan menggunakan semua sandi yang Anda harapkan.

Jadi tidak perlu menerbitkan ulang sertifikat.


Ini berfungsi untuk saya dalam situasi yang serupa, tetapi agak berlawanan dengan, pertanyaan awal: peran AD FS pada Windows Server 2012 R2 mengharuskan Anda menggunakan Legacy API untuk permintaan sertifikat - tetapi kemudian hanya menunjukkan 2 kode sandi AES ditunjukkan di atas! Mengekspor, mengemas ulang kunci dengan OpenSSL, dan mengimpor kembali memecahkannya sama - protokol lain tiba-tiba mulai berfungsi. Terima kasih, @gelilloadbad!
ewall

0

Terima kasih, pos Anda membantu saya, meskipun masalah saya tidak persis sama.

Namun, penyebabnya adalah kesalahan konfigurasi WINHTTP SERVER API di pihak saya. IP saya berubah, dan ketika saya memasukkan sertifikat server baru ke mesin "MY", saya mengabaikan kode pengembalian ALREADY_EXISTS untuk HttpSetServiceConfiguration.

Jadi saya menggunakan sertifikat TLS server sebelumnya yang memiliki nama umum yang salah dan tidak cocok dengan nama server baru saya.

Jika Anda tidak melakukan HttpDeleteServiceConfiguration () atau baris perintah "netsh http delete sslcert 0.0.0.0:8443" dengan benar, Anda akan mendapatkan kesalahan buruk dengan gejala-gejala ini:

1) Dalam TLS, Halo Klien Anda segera bertemu dengan paket TCP dari server Anda dengan Ack dan Reset bit flag yang ditetapkan. (Peringatan kegagalan jabat tangan, saya pikir?)

2) Penampil acara mendapatkan "Peringatan fatal berikut ini dihasilkan: 40. Status kesalahan internal adalah 107."

"Permintaan koneksi SSL 3.0 diterima dari aplikasi klien jarak jauh, tetapi tidak ada suite sandi yang didukung oleh aplikasi klien yang didukung oleh server. Permintaan koneksi SSL telah gagal."

Jadi sebelum Anda mengejar ketidakcocokan suite sandi, pastikan Anda benar-benar menggunakan sertifikat server yang ingin Anda gunakan dengan:

         netsh http show sslcert

dan periksa nilai hash!


Jawaban ini sangat tidak jelas dan tidak masuk akal. Anda harus bertujuan untuk langsung menjawab "Mengapa Window Cipher-Suite Window dibatasi oleh sertifikat SSL tertentu?" dan tindak lanjuti dengan penjelasan tentang kesalahan Schannel.
Bernie White

0

Ini bisa menjadi masalah KeySpec = 2 - AT_SIGNATURE

certutil -verifystore -v My "Thumbprint of cert" untuk memverifikasi nilai KeySpec. Jika 2, Anda harus mengekspor sertifikat sebagai file PFX dan kemudian menjalankan certutil -importpfx AT_KEYEXCHANGE untuk memperbaikinya.


Itu adalah masalah dalam kasus saya juga. Sebenarnya, jawaban ini adalah satu-satunya yang benar-benar berusaha menunjukkan penyebabnya. Namun, jawabannya akan mendapat manfaat dari penjelasan mengapa AT_SIGNATURE tidak cukup untuk cipher suite non-ECDHE - karena untuk suite tersebut RSA digunakan tidak hanya untuk otentikasi (tanda tangan), tetapi juga untuk pertukaran kunci.
Jakub Berezanski
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.