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

14

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”

Gary
źródło
2
Gary, jeśli rozwiązałeś swoje pytanie, zaznacz je jako odpowiedź.
Bernie White,

Odpowiedzi:

14

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.

Gary
źródło
Czy ktoś wie, jak to zrobić - lub w inny sposób rozwiązać problem - w przypadku certyfikatów z podpisem własnym?
MGOwen
Bardzo dziękuję Gerry za pracę i udostępnianie wyników! Otworzyliśmy Microsoft Support Case, a sam Microsoft nie był w stanie dowiedzieć się, dlaczego niektórzy klienci nie mogą się połączyć. Mamy problem dokładnie tak, jak opisałeś. Ale zgodnie z technet.microsoft.com/en-us/library/ff625722(v=ws.10).aspx Microsoft sam zaleca używanie Starszego szablonu klucza do zarchiwizowania najlepszej kompatybilności! Świetna robota!
2

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.

Angel Abad Cerdeira
źródło
Działa to dla mnie w sytuacji podobnej, ale nie przeciwnej do pierwotnego pytania: rola usług AD FS w systemie Windows Server 2012 R2 wymaga użycia starszego interfejsu API dla żądania certyfikatu - ale wtedy pokazuje tylko 2 szyfry AES pokazane powyżej! Eksportowanie, przepakowywanie klucza za pomocą OpenSSL i ponowne importowanie rozwiązuje go tak samo - inne protokoły nagle zaczynają działać. Dzięki, @gillilloadbad!
ewall
0

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!

AndrewDover
źródło
Ta odpowiedź jest bardzo niejasna i nie ma większego sensu. Powinieneś dążyć do bezpośredniej odpowiedzi na pytanie „Dlaczego pakiet szyfrujący SSL systemu Windows podlega ograniczeniom na podstawie niektórych certyfikatów SSL?” i wyjaśnij błąd Schannela.
Bernie White,
0

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ć.

Michael
źródło
Tak było również w moim przypadku. W rzeczywistości ta odpowiedź jest jedyną, która faktycznie próbuje wskazać przyczynę. Odpowiedź skorzystałaby jednak z wyjaśnienia, dlaczego AT_SIGNATURE jest niewystarczający dla zestawów szyfrów spoza ECDHE - ponieważ dla takich pakietów RSA służy nie tylko do uwierzytelnienia (podpisu), ale także do wymiany kluczy.
Jakub Berezański