Keine der von der Clientanwendung unterstützten Cipher Suites wird vom Server unterstützt


9

Ich erhalte diesen Fehler im Windows-Ereignisprotokoll meines Servers:

Eine TLS 1.0-Verbindungsanforderung wurde von einer Remoteclientanwendung empfangen, aber keine der von der Clientanwendung unterstützten Cipher Suites wird vom Server unterstützt. Die SSL-Verbindungsanforderung ist fehlgeschlagen.

Wenn ich versuche, über eine Windows Server 2003-Box eine Verbindung zu einem Webdienst auf einer Windows 7-Box herzustellen.

Wie füge ich einer von der anderen unterstützten eine Verschlüsselungssuite hinzu?

(Das Reparieren von Clients ist ideal, aber wenn eine Serverlösung nicht in Ordnung ist, habe ich Zugriff auf alle beteiligten Boxen. Ich möchte aus Datenschutzgründen nur eine grundlegende Verschlüsselung zwischen ihnen.)

Zusammen mit stundenlangem googeln und lesen habe ich versucht:

  • Überprüfte Server-Windows-Ereignisanzeige (Fehler in der Cipher Suite gefunden)
  • Es wurden Cipher Suites zu test1 von http://support.microsoft.com/kb/948963 hinzugefügt (hat nicht geholfen)
  • TLS 1.0 zu Protokollen in Cipher Suites in der Windows-Registrierung des Servers hinzugefügt (keine Änderung)
  • Installieren Sie IIS-Tools in der Hoffnung, dass Schannel um weitere Protokolle erweitert wird (dies ist nicht der Fall).
  • Exportzertifikat für Clients erneut, jedoch mit privatem Schlüssel (keine Änderung)
  • Überprüfen Sie, ob die installierten Cipher Suites auf Server und Client übereinstimmen (kann nicht finden, wo win2k3 sie auflistet).
  • Fügen Sie TLS_RSA_WITH_AES_256_CBC_SHA (installiert durch den obigen Hotfix) zu den Cipher Suites des Servers hinzu (nein, bereits vorhanden).

@sohnee serverfault.com/questions/166750/… Garys Antwort auf diese Frage trägt in gewisser Weise zur Beantwortung dieser Frage bei.
Drifter104

Sie wissen das wahrscheinlich schon, aber ich werde es trotzdem für diejenigen posten, die es vielleicht nicht wissen. Windows 2003 wird von Microsoft nicht mehr unterstützt und erhält keine Updates mehr. Wenn Sie 2k3 verwenden, sollten Sie migrieren oder aktualisieren.
Liczyrzepa

Dieses Problem ist auch auf Server 2008 sichtbar (und wahrscheinlich 2012, obwohl ich hier 2012 noch kein SSL habe).
Fenton

Antworten:


5

Windows 7 verwendet bei der Auswahl von Chiffren die neue CNG-API (Cryptography Next Generation). CNG für Windows 2003 ist meines Wissens nicht verfügbar.

Sie können diese AES-basierten Cipher Suites jedoch für die Verwendung unter Windows 2003 installieren:

  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_CBC_SHA

Dies sind die ersten Suites, die Windows Vista- und Windows 7-Clients versuchen, für die Verwendung mit TLS 1.0 und höher auszuhandeln. Sie werden auch von OpenSSL-Clients unterstützt.

Um diese zu verwenden, installieren Sie KB948963


1
Vielen Dank! Ich hätte erwähnen sollen, dass ich das bereits versucht habe - es hat das Problem für mich nicht gelöst. Vielleicht lehnt die andere Box sie immer noch ab, weil CBC nicht mehr als sicher gilt? Sie befinden sich jedoch in der Liste der Chiffresuiten. Was kann ich also noch tun? :(
MGOwen

Interessant, wie die Community funktioniert. Jetzt ist die beste Antwort auf diese Frage eine, die nie funktioniert hat, und die eigentliche Antwort wird abgelehnt ... Ich gehe davon aus, dass SHA1 einige Jahre nach dem langen Vergessen dieser Frage veraltet ist. Hoffentlich hilft diese Antwort jemandem - oder niemand ist mehr gezwungen, Win 2k3-Server zu unterstützen ...
MGOwen

1
@ MGOwen Es tut mir leid, dass ich dir nicht helfen konnte. Ich habe persönlich ein ähnliches Problem wie das Ihre mit dem von mir verlinkten Hotfix gelöst. Hoffentlich spiegeln die positiven Stimmen die Anzahl der Personen wider, die diese Antwort nützlich fanden
Mathias R. Jessen

-1

Die Lösung bestand darin, mein Zertifikat erneut zu generieren und diesmal RSA und SHA1 zu erzwingen (obwohl SHA1 sowieso die Standardeinstellung ist). Aus irgendeinem Grund konnte oder wollte Win Server 2k3 nicht die richtigen Chiffren mit einem Standard-Makecert-Zertifikat verwenden. Hier ist die Befehlszeile, die für mich funktioniert hat:

makecert -pe -r -ss my -sr localMachine -n ​​"CN = domainnameoripaddressgoeshere.com" -e 01/01/2098 -a sha1 -eku 1.3.6.1.5.5.7.3.1 -sky exchange -sp "Microsoft RSA SChannel Kryptografieanbieter "-sy 12

Weitere Informationen finden Sie unter http://mgowen.com/2013/06/19/cipher-suites-issue/ und http://msdn.microsoft.com/en-us/library/bfsktky3(v=vs.110).aspx .


3
sha1 ist veraltet. Ich vermute, das Problem ist aufgetreten, weil alle von Ihrem 2003-Client unterstützten Chiffren aufgrund von Sicherheitsentwicklungen in den letzten Jahren veraltet sind. Wenn Sie diese Chiffren wieder öffnen, werden wahrscheinlich Sicherheitslücken geöffnet. Beachten Sie auch, dass Google Sie bestraft, wenn Sie SHA1 für ein Website-Zertifikat verwenden. community.qualys.com/blogs/securitylabs/2014/09/09/…
mc0e

1
Der Ausdruck "SHA1 sollte sowieso die Standardeinstellung sein" trifft wahrscheinlich auf den Kontext zu, den Sie wahrscheinlich verwendet haben, aber wie @ mc0e sagte, ist er aufgrund von Sicherheitsproblemen veraltet, und heutzutage würde dieser Ausdruck Schauer über die Stacheln von IT- und Sicherheitsexperten schicken . Stellen Sie sicher, dass Sie nach Möglichkeit SHA-2 (SHA-256) verwenden, da dies derzeit der Standard ist.
Rubynorails

Danke Rubynorails. Ich habe meine Antwort bearbeitet und gemeint, dass SHA1 die Standardeinstellung für makecert ist (2013, als ich das schrieb, nicht sicher, ob es neuere Versionen von makecert gibt, für die dies nicht mehr der Fall ist). Ich werde sehen, ob wir noch SHA1 verwenden, und überlegen, ob es sich lohnt, makecert dazu zu bringen, etwas anderes zu verwenden und unsere Zertifikate erneut zu erstellen (nicht für ein öffentlich zugängliches Produkt).
MGOwen

Damit Server2003 SP2 ein SHA-256-Zertifikat akzeptiert (überprüft), ist ein weiterer Hotfix support.microsoft.com/en-us/kb/938397 erforderlich . (XP SP2 erforderte dies ebenfalls, bekam aber SP3 mit dem Fix, bevor die Unterstützung endete.)
dave_thompson_085
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.