Dlaczego pakiet szyfrujący SSL systemu Windows podlega ograniczeniom na podstawie niektórych certyfikatów SSL?

Problem: Windows Server 2008 R2 obsługuje tylko następujące zestawy szyfrów ssl podczas używania niektórych certyfikatów na serwerze:

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

Zapobiega to nawiązywaniu przez klientów XP połączenia z serwerem, ponieważ API XP Cryptographic domyślnie nie obsługuje żadnych szyfrów AES.
W rezultacie następujące błędy pojawiają się w logach serwera podczas próby połączenia za pomocą przeglądarki Internet Explorer lub pulpitu zdalnego. (ponieważ używają CAPI firmy Microsoft)

Błąd Schannela 36874 „Odebrano połączenie TLS 1.0 ze zdalnej aplikacji klienckiej, ale serwer nie obsługuje pakietów szyfrów obsługiwanych przez klienta. Żądanie połączenia SSL nie powiodło się.”
Błąd Schannela 36888 „Wygenerowano następujący alert krytyczny: 40. Stan błędu wewnętrznego to 1204”

Jeśli certyfikat używany na serwerze został wygenerowany przy użyciu opcji Legacy Key w formularzu żądania certyfikatu, klucz prywatny dla tego certyfikatu będzie przechowywany w starszej strukturze Cryptographic API firmy Microsoft. Gdy serwer WWW próbuje przetwarzać żądania przy użyciu nowej struktury Cryptographic Next Generation (CNG), wydaje się, że coś związanego z kluczem prywatnym RSA przechowywanym w starszej strukturze jest niedostępne dla nowej struktury. W rezultacie użycie zestawów szyfrów RSA jest poważnie ograniczone.

Rozwiązanie:
Wygeneruj żądanie certyfikatu za pomocą szablonu klucza CNG w niestandardowym kreatorze żądania certyfikatu.

MMC | Menedżer certyfikatów komputera lokalnego | Folder certyfikatów osobistych | (kliknij prawym przyciskiem myszy) | Wszystkie zadania -> Operacje zaawansowane | Utwórz zamówienie niestandardowe | „Kontynuuj bez zasad rejestracji” | wybierz „(bez szablonu) klucz CNG” | kontynuuj wypełnianie wniosku o certyfikat zgodnie z własnymi potrzebami.

Sprawdzanie, czy klucz znajduje się we właściwym miejscu:
http://msdn.microsoft.com/en-us/library/bb204778(VS.85).aspx
http://www.jensign.com/KeyPal/index.html

Narzędzia do weryfikacji poprawnych pakietów szyfrów:
http://pentestit.com/2010/05/16/ssltls-audit-audit-web-servers-ssl-ciphers/
https://www.ssllabs.com/

Ustawienia zestawu szyfrów 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-on-windows-vista.aspx

Zrozumienie tego zajęło nam tydzień. Mam nadzieję, że uratuje to komuś ten sam problem.

Dostałem dokładnie ten sam problem, a ten post oszczędził mi mnóstwo czasu, więc dziękuję wszystkim!

Rozwiązanie Gary'ego jest na miejscu, ale udało mi się rozwiązać problem, po prostu przekształcając PFX w PEM, a następnie z powrotem do PFX za pomocą openssl. Nowy PFX zaimportował certyfikat do IIS tak samo, z tą różnicą, że widzę brakujące szyfry.

Oto jak:

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

Następnie podziel plik cer na trzy, klucz, certyfikat i certyfikat pośredni [s]

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

Następnie, jeśli zaimportujesz nowy plik .pfx do IIS, użyje on wszystkich szyfrów, których oczekujesz.

Nie trzeba więc ponownie wystawiać certyfikatu.

Dzięki, twój post pomógł mi, chociaż mój problem nie był dokładnie taki sam.

Przyczyną był jednak błąd konfiguracyjny API SERWERA WINHTTP z mojej strony. Mój adres IP się zmienił, a kiedy umieściłem nowy certyfikat serwera w maszynie „MY”, zignorowałem kod powrotu ALREADY_EXISTS dla HttpSetServiceConfiguration.

Użyłem więc poprzedniego certyfikatu TLS serwera, który miał niepoprawną nazwę pospolitą i nie pasował do mojej nowej nazwy serwera.

Jeśli nie wykonasz poprawnie HttpDeleteServiceConfiguration () lub wiersza polecenia „netsh http delete sslcert 0.0.0.0:8443” poprawnie, pojawi się nieprzyjemny błąd z następującymi objawami:

1) W TLS twoje powitanie klienta jest natychmiast spotykane z pakietem TCP z twojego serwera z ustawionymi bitami flagi Ack i Reset. (Myślę, że ostrzeżenie o awarii uścisku dłoni?)

2) Przeglądarka zdarzeń otrzymuje komunikat „Wygenerowano następujący alert krytyczny: 40. Stan błędu wewnętrznego to 107.”

„Otrzymano żądanie połączenia SSL 3.0 ze zdalnej aplikacji klienckiej, ale serwer nie obsługuje żadnego zestawu szyfrów obsługiwanego przez aplikację kliencką. Żądanie połączenia SSL nie powiodło się.”

Dlatego zanim zaczniesz ścigać niedopasowanie pakietu szyfrów, upewnij się, że naprawdę używasz certyfikatu serwera, którego chcesz używać:

         netsh http show sslcert

i sprawdź wartości skrótu!

Może to być problem KeySpec = 2 - AT_SIGNATURE

certutil -verifystore -v Mój „odcisk palca certyfikatu” do weryfikacji wartości KeySpec. Jeśli jest to 2, musisz wyeksportować certyfikat jako plik PFX, a następnie uruchomić certutil -importpfx AT_KEYEXCHANGE, aby go naprawić.