06.05.2022

13092

Windows Server 2012R2 stellt keine TLS Verbindung her

Hallo,

seit Ende April stellt unser Windows Server 2012R2 keine Verbindung über die API zu Kaufland mehr her. Das muss irgendwas mit TLS zu tun haben. Es wurden keine neuen Updates eingespielt. Kaufland versichert mir, dass bei ihnen nichts geändert wurde. Ich kann auf dem Server über den IE die Webseite zur Kontrolle auch nicht aufrufen. Da wird mir auch nur ein TLS Fehler angezeigt.
Jetzt habe ich auch schon alle zur Verfügung stehenden Updates eingespielt, selbes Problem.
Hat jemand ein ähnliches Problem? Oder weiß jemand woran es liegen kann.?

Folgende Microsoft Anleitung könnte passen, aber nach dem Entfernen der Zertifikate, werden die bei mir nicht automatisch wieder über das Windows-Update gezogen. Oder mache ich was falsch.
https://docs.microsoft.com/de-de/troubleshoot/windows-server/windows-sec ...

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 2708072191

Url: https://administrator.de/contentid/2708072191

Ausgedruckt am: 08.11.2024 um 15:11 Uhr

58 Kommentare

Neuester Kommentar

Ich glaube niemand hier weiß was du willst.

Was für eine Meldung bzgl. TLS bekommst du denn?
Ist das OS selbst auf dem neuesten Stand bei Windows-Update?

Moin Therapiezentrum,

da fallen mir pauschal die folgenden Sachen ein.

- Kaufland unterstützt seinerseits TLS 1.0 und 1.1 nicht mehr und auf deiner Seite ist TLS 1.2 auf dem 2012R2
nicht aktiviert.

- Kaufland unterstützt nur noch TLS 1.3. In dem Fall hast du aber die A-Karte gezogen, weil der Server 2012R2 kein TLS 1.3 kann.

- Ihr habt euch eine neue FireWall angeschafft und oder an der bestehenden etwas an der "SSL/TLS-Inspection" verändert.

Beste Grüsse aus BaWü
Alex

Okay, danke. Das mit TLS 1.3 darauf bin ich nicht gekommen. Das werde ich mal checken.

Könnte auch an den supported TLS Cipher-Suites liegen, Kaufland akzeptiert hier mit TLS 1.2 nur 3 cipher
Evt wurden bei euch die zu verwendenden Ciphers für TLS1.2 angepasst.
Demystifying Schannel

Ein Mittschnitt der Kommunikation (fiddler &co.) sollte euch entsprechende Infos liefern.

Grüße Uwe

Moin Therapiezentrum,

Okay, danke. Das mit TLS 1.3 darauf bin ich nicht gekommen. Das werde ich mal checken.

TLS 1.3 wirst du auf einem 2012R2 nicht hinbekommen, aber eventuell ist TLS 1.2 nur nicht sauber "aktiviert".

Schau dir diesbezüglich mal das hier an.
https://docs.microsoft.com/de-de/mem/configmgr/core/plan-design/security ...

Und eventuell muss du auf dem Server das hier noch ausführen.

TLS 1.2 Clientseitig aktivieren:

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Force   
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -name 'Enabled' -value '1' -PropertyType 'DWord' -Force  
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -name 'DisabledByDefault' -value 0 -PropertyType 'DWord' -Force  

Beste Grüsse aus BaWü

Alex

Okay, Danke.

Die 3 Registry Einträge hatte ich nicht drin stehen. Aber geht bis jetzt immer noch nicht.

Zum Verständnis, der Server nimmt selbst die SSL Verbindung auf, oder läuft eine Software auf dem Server, die SSL/TLS dabei hat?

Wirkstoff ist die ein ein Begriff? Der Aufbau einer SSL/Verbindung lässt sich damit einsehen.

Also, auf unserem Server läuft eine Software, die über eine API die Verbindung zu Kaufland aufnimmt und Bestelldaten zu uns austauscht. Also nicht über eine Weboberfläche.
Seit zwei Wochen klappt die Übertragung nicht mehr. Dies betrifft aber nur 2012R2 Server.
Kaufland verwendet aktuell zur Verschlüsselung TLS 1.2. Laut Microsoft kann der 2012R2 TLS 1.2.

Komischerweise kann man auf den betroffenen Servern die Seite von Kaufland auch nicht im IE aufrufen. Das mit dem IE kann natürlich jetzt auch nur Zufall sein und muss nichts miteinander zu tun haben.

Was zeigt denn der IE als Fehler an?

Verschieden:
Wenn ich unter Internetoptionen -> Erweitert die SSL Zertifikate aktiviert habe, bekomme ich eine Seite "Die Seite kann nicht angezeigt werden"

Habe ich Haken bei SSL draußen und nur die Haken bei TLS drin, dann bekomme ich eine Seite das ich TLS aktivieren soll. Alle anderen Seiten mit SSL gehen dann aber immer noch.

Starte doch einfach mal fiddler dann siehst du auf den ersten Blick was Sache ist und ob irgenwelche ciphers deaktiviert wurden bzw. warum der Verbindungsaufbau fehl schlägt ...

Okay, habe ich mir mal heruntergeladen, wo sehe ich denn da jetzt was. Für dieses Problem reichen meine Kenntnisse nicht so tief.

Unter File sicherstellen das das Capturing(F12) aktiv ist. Dann in der Symbolleiste die Zielscheibe auf den InternetExplorer ziehen und fallen lassen. zur Seite gewünschten Seite navigieren dann in Fiddler die erste Connection zzum Server markieren und auf der rechten Seite den Tab "Inspectors" öffnen.
Will man den SSL-Traffic zusätzlich entschlüsseln lassen dann muss man das Content-Icpection-Zertifikat von Fiddler in den Root-Store installieren lassen, das geht entweder über den gelben Balken der erscheint oder unter Tools >Options > Https > Decrypt Https Traffic.
Evt zurückgelieferte Header und Meldungen über ausgehandelte Ciphers etc. sieht man dann auch im unteren Bereich in den unterschiedlichen Tabs.

Da stehen gleich 3 Einträge. Beim Ersten und Zweiten steht was mit SSLv3 kompatibel.
Beim Dritten steht überhaupt nichts.

Zitat von @Therapiezentrum:

Da stehen gleich 3 Einträge. Beim Ersten und Zweiten steht was mit SSLv3 kompatibel.
Beim Dritten steht überhaupt nichts.

Mit den erbärmlichen Infos können wir hier leider nichts anfangen, das mit SSLv3 erscheint fast weil das als Fallback konfiguriert ist, mach mal Screenshots von den unteren Tabs (Headers > Raw und Textview).
Ansonsten lass da mal jemanden vor Ort ran der Ahnung von der Materie hat.

Dachte ich mir schon. Hier die beiden Screenshots vom ersten Eintrag:

Im Fensterteil darunter musst du prüfen ob eine Antwort (Response) kommt, dein Screenshot ist nur vom Connect also der Anfrage! Dazu am besten https decryption aktivieren.

Du kannst auch im linken Connection Fenster die Verbindung markieren und SHIFT+ENTER drücken, im erscheinendne Fenster kannst du dann zwischen Request und Response wechseln.

So, jetzt blockiert mir Fiedler den Datenverkehr. Alle Browser können nichts mehr anzeigen, bis ich Fieddler beende oder den Haken für das Fiedler Zertifikat rausnehme

Zitat von @Therapiezentrum:

So, jetzt blockiert mir Fiedler den Datenverkehr. Alle Browser können nichts mehr anzeigen, bis ich Fieddler beende oder den Haken für das Fiedler Zertifikat rausnehme

Das ist normal, es startet einen Proxy und trägt den in den IE Settings ein so lange es läuft

.
In den Optionen unter Tools > Options > Https >Protocols kannst du festlegen mit welchen TLS Varianten sich Fiddler mit den Seiten verbinden kann wenn die natürlich zu eingeschränkt sind dann kommt keine Verbindung zu stande logisch.

Man muss sich halt etwas damit beschäftigen, von selbst ist der Gavatter nich tot. Lass es, das wird hier so nichts mehr ... Hol dir am besten vor Ort Hilfe.

Jetzt bekomme ich nur noch einen Result 502 vorher hatte ich immer den Status 200

Moin Therapiezentrum,

Jetzt bekomme ich nur noch einen Result 502 vorher hatte ich immer den Status 200

Ich habe noch Zugriff auf diverseste 2012R2 RDS Server, welchen Link rufst du den genau auf?
Wenn du diesen hier nicht öffentlich posten möchtest, dann schick mir einfach eine PN.

Beste Grüsse aus BaWü
Alex

P.S. Welche FireWall/Security-Gateway habt Ihr im Einsatz?

Das mit der Verbindung zu Kaufland lief jetzt 3 Jahre problemlos. Seit einer Woche geht es nicht mehr. die letzten Updates des Servers sind bestimmt schon ein paar Monate her.
Die Software bezieht die Daten direkt über die Kaufland Rest-Schnittstelle der API. Die Verschlüsselung ist TLS 1.2
Das ist genau das Problem, worum es eigentlich geht.

Hier ist die Schnittstelle Beschreibung: www.kaufland.de/api/v1/?page=rest-api

Moin Therapiezentrum,

das ist gut, wenn ich bei mir auf einem 2012R2 RDS die Kauflandseite aufrufe, dann bekomme ich direkt die folgende Fehlermeldung.

Lass mich mal meine beiden Hausdrachen füttern und dann schaue ich wie wir diese Kuh vom Eis bekommen. 😀

Beste Grüsse aus BaWü
Alex

Ja, so sieht das bei mir auch aus. Ich weiß nur nicht, ob das im IE nicht schon immer war.
Die Verbindung baut die Software hintenrum per TLS 1.2 auf. Mit der alten Domain (real.de) geht es noch.

Ist denn TLS1.2 in inetcpl.cpl aktiviert?

Ja, ist dort alles aktiviert.

Teste mal damit: https://browserleaks.com/ssl

Geht außer TLS 1.3 alles okay

Ja, so sieht das bei mir auch aus. Ich weiß nur nicht, ob das im IE nicht schon immer war.
Die Verbindung baut die Software hintenrum per TLS 1.2 auf. Mit der alten Domain (real.de) geht es noch.

Hast du mal versucht die Seite mit Chrome auf dem 2012R2 aufzurufen?

Zitat von @Therapiezentrum:

Geht außer TLS 1.3 alles okay

Die Cipher suites wären jetzt interessanter gewesen, denn laut Doku sind die vom Kaufland Server aktivierten ECDHE und ChaChaPoly Suites nicht in Server 2012R2 aktiv und der IE nutzt ja das systemweite SCHANNEL
https://docs.microsoft.com/de-de/windows/win32/secauthn/tls-cipher-suite ...

Chrome ist da nicht installiert. Aber auf meinem Win7 Rechner geht das im IE auch nicht, in den anderen Browser klappt das alles. Was unterscheidet denn die real.de von der kaufland.de?
Die API über die real aufgerufen funktioniert noch.

Na ja, zwischen www.real.de und www.kaufland.de gibt es schon diverse Unterschiede.

Kaufland:

Real:

So wie ich das sehe, hat Kaufland wahrscheinlich jüngst auf TLS 1.3 umgestellt und dabei sind wohl ein paar TLS 1.2 Clipher über den Jordan gegangen. ☹

https://www.ssllabs.com/ssltest/analyze.html?d=www.kaufland.de

Eben, wie geschrieben fehlen die ECDHE GCM Suites in Server2012R2... W8.1 ist ja identischer Unterbau.

Das sieht echt bescheiden aus, der Server 2012R2 unterstützt keine der drei von Kaufland verwendeten TLS 1.2 Ciphers.

☹
Den Spruch mit "Wir haben bei uns nichts geändert", können die sich übrigens sonst wohin stecken.

Zitat von @2423392070:

Ich glaube niemand hier weiß was du willst.

Du musst deine Kristallkugel wohl noch etwas besser polieren. 😉

Okay, was kann man tun? Ich habe noch den nachfolgenden Workaround von Microsoft gefunden:
Allerdings, wenn ich wie beschrieben, zieht sich der Server die Zertifikate nicht automatisch neu, oder fehlt da bei mir auch irgendwo ein Haken.
WSUS läuft auf dem Server nicht, weil der nur SQL bereistellt und die Datenabgleiche macht.

https://docs.microsoft.com/de-de/troubleshoot/windows-server/windows-sec ...

Zitat von @Therapiezentrum:

Okay, was kann man tun?

Da gibt es mehrere Optionen:

Man schaltet einen SSL Proxy wie bspw. squid dazwischen, hat den Vorteil das man an der Clientanwendung nichts ändern muss, außer das man dem SSL-Proxy Zertifikat sein Vertrauen schenken muss indem man es in die Stammzertifikate mit aufnimmt. Ein Proxy lässt sich auch nur für diese eine Anwendung konfigurieren ohne das man zwingend sämtlichen Traffic durch den Proxy jagen muss.

Man nutzt für den API Zugriff in der Anwendung eine externe SSL Bibliothek die nicht von SCHANNEL abhängig ist, vorzugsweise dann auf OpenSSL basierte zurückgreifen.
Man aktualisiert vorausschauend das Betriebssystem (Supportende für 2012R2 ist Oktober 2023, außer man kauft ext. Support). Denn die Probleme werden wohl nicht weniger wenn immer mehr Seiten die Suites mit der Zeit hoch ziehen.

Ich habe noch den nachfolgenden Workaround von Microsoft gefunden:
Allerdings, wenn ich wie beschrieben, zieht sich der Server die Zertifikate nicht automatisch neu, oder fehlt da bei mir auch irgendwo ein Haken.
https://docs.microsoft.com/de-de/troubleshoot/windows-server/windows-sec ...

Das hat eher Einfluss darauf wenn ein Client sich mit einem Zertifikat autorisieren muss, ist hier aber nicht der Fall.

Na ja, wenn sich mein Server bei Kaufland anmeldet, um dort Daten abzuholen, ist mein Server nicht in dem Moment der Client?

Zitat von @Therapiezentrum:

Na ja, wenn sich mein Server bei Kaufland anmeldet, um dort Daten abzuholen, ist mein Server nicht in dem Moment der Client?

Das schon, aber du nutzt zur Anmeldung bei Kaufland ja kein "Client"-Zertifikat und darum ging es primär im KB ...
Und da die Ciphers von Kaufland nicht vom OS unterstützt werden kannst du an den Zertifikaten noch so viel schrauben.

Aktualisieren macht noch keinen Sinn. Der Windows Server 2022 und der zugehörige SQLer werden von den Anwendungen noch nicht unterstützt. Und wenn ich den Server wechsele sollte der dann vorausschauend auch TLS 1.3 unterstützen. Also heißt es warten, bis ich den Win2022 gefahrlos nutzen kann.

SQL und Anwendungsserver lassen sich trennen btw.😉

Dann eben wie oben geschrieben einfach squid in ne Mini VM packen und als SSL Proxy verwenden, schnell, schmerzlos und kost nix 🙂.

Aktualisieren macht noch keinen Sinn. Der Windows Server 2022 und der zugehörige SQLer werden von den Anwendungen noch nicht unterstützt.

Wie kommst du auf diese Idee?
Und sag jetzt bitte nicht, das sagt der Hersteller.

Einfach mal eine 2022 VM aufsetzen und testen. 😉

Bedeutet das jetzt, dass sich das Problem mit dem 2012R2 nicht lösen lässt?

Jain, das mit dem Proxy wie colinardo es vorschlägt, könnte funktionieren.

Ansonsten ändert Kaufland entweder die TLS 1.2 Ciphers oder du musst auf eine Server-Version gehen,
die die jetzigen TLS 1.2 oder 1.3 Ciphers unterstützt.

Gemäss diesen Angaben, werden die von Kaufland verwendeten TLS 1.2 Ciphers schon ab Server 2016 unterstützt.
https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-cipher-suite ...

Die TLS 1.3 Ciphers, werden erst ab Server 2022 unterstützt.

Welche FireWall hast du im Einsatz?

Die normale Windows-Firewall und das Netzwerk selber hat eine Linux Firewall.

Jetzt kommt die große Frage: Sind das 2 getrennte Zertifikate bei Kaufland, also TLS 1.2 und TLS 1.3 oder kann das auch ein Kombi-Zertifikat sein?

Zitat von @Therapiezentrum:

Jetzt kommt die große Frage: Sind das 2 getrennte Zertifikate bei Kaufland, also TLS 1.2 und TLS 1.3 oder kann das auch ein Kombi-Zertifikat sein?

Das Zertifikat selbst hat nichts mit den TLS-Protokollen und Ciphern zu tun, das ist nur ein Teil des ganzen und dient primär der Identifikation und erst im zweiten Schritt zur Signatur und Verschlüsselung der Nachrichten.
Die Web-Serversoftware bestimmt welche Protokolle mit welchen Ciphern er dem Client offeriert. Das kann man bei Apache/nginx &co. nach Bedarf bzw. Bibliothek Support konfigurieren.
Bevor wir jetzt hier mit den Grundlagen des Public-Key-Verschlüsselungsverfahrens anfangen, beließ dich doch bitte dazu.
https://entwickler.de/security/sicher-auf-dem-server-unterwegs

Oder anders gefragt, können die das bei Kaufland ändern?

Zitat von @Therapiezentrum:

Oder anders gefragt, können die das bei Kaufland ändern?

Ja das beschränkt sich in der Regel auf die Änderung einer Config-Zeile (nginx/Apache), aber ob die wegen einem upgradeunwilligen Kunden wollen ist dann ein anderes Blatt, die werden dir vermutlich das selbe husten.
Wenn bei mir bspw. jemand anrufen würde ob ich doch nicht die Sicherheit der Kundendaten wegen ihm runterschrauben könnte (wäre zwar hier nicht der Fall mit ein paar mehr noch als sicher geltenden Ciphern) dem würde ich auch was husten, außer der Kunde bringt mir einen nicht unerheblichen Umsatz, dann würde man vermutlich zwei mal nachdenken und an einer Lösung zusammen mit dem Kunden arbeiten 😉
Aber wenn du es versuchen willst, tu dir keinen Zwang an, aber beschwere dich hinterher nicht, dass die dir evt eine Therapie in eurem eigenen Zentrum empfehlen 😅

Schönen Sonntag noch
Grüße Uwe

Das betrifft einige Händler und bedeutet ja auch für Kaufland Umsatzverlust. Du glaubst gar nicht, wie viele Leute das Problem haben. Und selbst wenn die Händler wollten, können die das nicht von heute auf morgen wechseln, zumal der 2012R2 nach fast 2 Jahre von MS unterstützt wird.

Werden die Daten unsicherer, wenn bei TLS 1.2 wieder die alte Anzahl an Cliphers vorhanden ist?
Das TLS 1.2 war doch vorher auch schon in Nutzung.

Na, ich rufe da mal den Support an und frage da mal nach. Dummerweise trifft das keine Leute, die alte Desktop-Systeme verwenden.

Zitat von @Therapiezentrum:
Und selbst wenn die Händler wollten, können die das nicht von heute auf morgen wechseln, zumal der 2012R2 nach fast 2 Jahre von MS unterstützt wird.

Ein fitter Admin wäre sicher dazu in der Lage, aber das ist ein anderes Blatt.

Werden die Daten unsicherer, wenn bei TLS 1.2 wieder die alte Anzahl an Cliphers vorhanden ist?

So lange man dort auf bewährte Ciphers setzt, und nicht RC4,MD5 &Co aktiviert, nein, nicht wirklich.

Dummerweise trifft das keine Leute, die alte Desktop-Systeme verwenden.

Da würde ich nicht dumm sagen wenn die User aktuelle Browser wie Firefox, Chrome &Co. einsetzen die ihre eigenen SSL Bibliotheken verwenden und nicht die von Windows, deshalb tangiert die das nicht!
Wenn man eben bis ganz zum Schluss mit den Updates wartet dann muss man halt manchmal mit solchen Widrigkeiten leben.
Stillstand holt einen eben irgendwann ein, das ist in der Branche so sicher wie das Amen in der Kirche.

Das Kaufland das aber stillschweigend umstellt ohne die Kunden zu benachrichtigen oder vorzuwarnen, ist dann aber doch unschön und gehört sich definitiv anders kommuniziert falls das tatsächlich so war.

Moin Therapiezentrum,

der Server 2012R2 unterstütz die folgenden TLS 1.2 Ciphers.

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 *
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 *
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521 *
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256 *
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384 *
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521 *
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P256 *
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384 *
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521 *
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P384 *
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521 *
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 *
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 *
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_NULL_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 *
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384 *
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521 *
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P384 *
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521 *

Und alle die ein Sternchen dahinter haben, gelten laut der folgenden und auch aktuellen Doku des BSI als sicher. 😉

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Techni ...

Na, ich rufe da mal den Support an und frage da mal nach. Dummerweise trifft das keine Leute, die alte Desktop-Systeme verwenden.

Wenn du nicht gerade den faulsten Admin bei Kaufland erwischst, dann sollte die Aktivierung der zusätzlichen
Cipher kein grosses Problem sein.

Wenn die nicht wissen wie man die Cipher erweitert, dann dürfen die sich natürlich gerne auch hier melden. 🤪

Beste Grüsse aus BaWü
Alex

@colinardo
Heute Abend ist aber ein TLS Entspannungs-🍺 fällig. 🙃

Zitat von @MysticFoxDE:

@colinardo
Heute Abend ist aber ein TLS Entspannungs-🍺 fällig. 🙃

Definitiv 🙂. Prost 🍻!

p.s. hab hier gerade auch die IKEv2 Cipher meines MIkrotik RB4011 auf AES-GCM aktualisiert, der hat ja durch seinen Annapurna Proz. auch Hardwarebeschleunigung dafür an Bord. Einer der wenigen der Mikrotiks der auch das mittels Hardware beschleunigt, jetzt fluppt das ganze noch etwas geschmeidiger 👍.

Ich danke euch allen für die hilfreiche und schnelle Unterstützung.
Das hat auf jeden Fall meinen Horizont fachkundig erweitert.

Ist denn überhaupt sicher, dass die Software keine eigene SSL Implementierung hat?
Wenn der Stack des weitverbreiteten Servers diesen Fehler aufweist, dann ist es schon seltsam, dass nicht mehrere Kunden das Problem haben.
Wie heißt denn die Software überhaupt?