SChannel-Fehler nach der Aktivierung von SSL auf einem Windows Server 2012 R2
Ich habe eine Windows Server 2012 R2-Instanz auf Azure. Für eine neue Website habe ich ein Zertifikat von GlobalSign bestellt. Nachdem ich die Zertifikate von ihnen erhalten habe, habe ich die Zertifikatsanforderung in IIS abgeschlossen und das Stammzertifikat installiert.
Ich habe die Website auf eine neue Instanz verschoben, also habe ich das Zertifikat mit seinem privaten Schlüssel exportiert und es auf der neuen Instanz importiert.
Das war meine Installation, und sie schien ziemlich gut zu funktionieren.
Jetzt bekomme ich eine Menge SChannel-Fehler. Sie lauten:
Ein fataler Alarm wurde erzeugt und an den entfernten Endpunkt gesendet. Dies kann zur Beendigung der Verbindung führen. Der im TLS-Protokoll definierte fatale Fehlercode ist 40. Der Windows SChannel-Fehlerstatus lautet 1205.
Ein fataler Alarm wurde generiert und an den entfernten Endpunkt gesendet. Dies kann zur Beendigung der Verbindung führen. Der im TLS-Protokoll definierte fatale Fehlercode ist 20. Der Windows SChannel-Fehlerstatus lautet 960.
Eine SSL 3.0-Verbindungsanfrage wurde von einer entfernten Client-Anwendung empfangen, aber keine der von der Client-Anwendung unterstützten Cipher Suites wird vom Server unterstützt. Die SSL-Verbindungsanforderung ist fehlgeschlagen.
Es ist das erste Mal, dass ich SSL verwende, und um ehrlich zu sein, habe ich keine Ahnung, was ich da tue. Für mich sieht es gut aus, wenn ich die Website aufrufe (http://laola.biz).
Ich habe bereits den SSL-Check von GlobalSign verwendet, der mir die Note C gibt. https://sslcheck.globalsign.com/en_US/sslcheck?host=laola.biz#191.233.85.240-cert-ssl
Hier eine Liste der Zertifikate von mmc (meine Website ist laola.biz):
Irgendwelche Ideen, was ich hier falsch gemacht haben könnte?
Da verschiedene Personen (ob wohlmeinend oder nicht) versuchen, von verschiedenen Geräten mit verschiedenen Browsern auf verschiedenen Betriebssystemen auf Ihre Website zuzugreifen, werden Sie je nach dem Protokoll, das sie zur Sicherung der Kommunikation wählen, am Ende Nachrichten von der Kanalquelle sehen.
Der folgende Blog soll Ihnen helfen, einige der Meldungen zu verstehen, die Sie in Ihren Protokollen sehen. http://blogs.msdn.com/b/kaushal/archive/2012/10/06/ssl-tls-alert-protocol-amp-the-alert-codes.aspx
Die Bewertung, die Sie dort erhalten haben, ist ein wenig beunruhigend. Sie würden SSL3 nicht aktiviert haben, wenn Sie die Website direkt auf Azure Websites veröffentlicht hätten.
Sie können SSL3 mit Hilfe der Anleitung hier deaktivieren http://blogs.msdn.com/b/kaushal/archive/2014/10/22/poodle-vulnerability-padding-oracle-on-downgraded-legacy-encryption.aspx
Wenn Sie die Site von einer VM auf eine Azure-Website selbst verschieben können, wäre das besser. So müssen Sie die VM(s), die zum Hosten der Website verwendet werden, nicht patchen und sichern. Sie verlassen sich stattdessen auf Azure PaaS, um die Plattform für das Hosten der Website bereitzustellen. Sie kümmern sich um den Code der Website, während Azure den IIS/die Plattform sichert und pflegt.
Die bevorstehenden Änderungen an der Plattform aus der TLS-Perspektive sind in https://testsslclient.trafficmanager.net/ enthalten. Sie können dies testen, um zu sehen, welche Einstufung Ihre Website erhalten kann, wenn Sie die Website direkt auf eine Azure-Website migrieren würden.