Exchange 2013, SP1 > Fehler: Quelle = Schannel, Ereignis-ID = 36874

[andrew 15]

hello together

 

 

Situation

> Exchange 2013 SP1 heute frisch installiert (Testumgebung)

> nach dem Einloggen via https://domainname.ch/ecp mit dem Administrator Account erscheint:

--------------------------

Die Website kann diese Seite nicht anzeigen HTTP 500

--------------------------

 

Betreffend Ereignis-ID 36888, Quelle=Schannel (pro Minute mehrere solche Einträge), Fehlertext lautet:

--------------------------

Es wurde eine schwerwiegende Warnung generiert und an den Remoteendpunkt gesendet. Dies kann dazu führen, dass die Verbindung beendet wird. Die schwerwiegende Warnung hat folgenden für das TLS-Protokoll definierten Code: 40. Der Windows-SChannel-Fehlerstatus lautet: 1205.

--------------------------

 

 

Betreffend Ereignis-ID 36874, Quelle=Schannel ((pro Minute mehrere solche Einträge), Fehlertext lautet:

--------------------------

Eine TLS 1.2-Verbindungsanforderung wurde von einer Remoteclientanwendung übermittelt, jedoch werden keine der Verschlüsselungssammlungen, die von der Clientanwendung unterstützt werden, vom Server unterstützt. Fehler bei der SSL-Verbindungsanforderung.

--------------------------

 

 

Vor dem Deinstallieren des alten Exchange 2013 (auf virtuellem Server 2012 R2) plötzlich auch diese Schannel Meldungen in der Ereignisanzeige vorgefunden, mit dem Unterschied, dass das erfolgreiche Einloggen (ECP oder OWA) via Administrator Account NICHT mit einer weissen Seite quittiert wurde!

 

Habe eine bestehende PKI, RootCA & SubCA (untergeordnete CA > signierende CA), diese läuft schon längere Zeit soweit mir bekannt ist, ohne Probleme.

 

 

Bemerkung Exchange Neuinstallation und danach

> hatte doch recht Probleme, den Exchange 2013 via Setup.exe /mode:uninstall zu deinstallieren. Erst beim Dritten Versuch mir das Setup.exe quittiert, dass die Deinstallation nun durch sei (musste hierzu die noch teils laufenden Exchange Dienste von Hand beenden, weil die Setup.exe Deinstallationsroutine, zumindest in meinem Fall nicht in der Lage war, die entsprechenden Dienste zu beenden.

 

> Danach hatte ich auf dem gleichen, virtuellen Server 2012 R2 ebenfalls wieder Probleme, den Exchange 2013 SP1 zu installieren.

> musste mit dem ADSI Edit nachhelfen, schlussendlich bin ich betreffend Exchange 2013 Säuberung gemäss diesem Link hier vorgegangen http://www.administrator.de/wissen/exchange-2013-aus-dem-active-directory-l%C3%B6schen-206569.html

 

 

Nach erfolgreicher Installation des Exchange 2013 und der Anpassung der virtuellen Verzeichnisse (alle URLs, intern wie extern) auf https://meinedomain.ch abgeändert. Der Aufruf von OWA/ ECP usw. funktioniert ohne Zertifikatsfehlermeldung.

 

Da Probleme nach dem Einloggen mit dem Administrator Account (danach weisse Seite) habe ich für einen bestehenden 0815 Benutzer, welcher schon im ADDS vorhanden war, diesem ein Postfach zugewiesen und OWA getestet.

 

Zuerst sah alles gut aus, es sah danach aus, als würde ich bald nach dem Einloggen die gewohnte OWA Webseite zu Gesicht bekommen, doch weit gefehlt, nach dem kurz noch den Text zu lesen war: Postfach wird geöffnet (oder so ähnlich) kam dann gleich folgende Fehlermeldung

--------------------------

:-(

something went wrong

Sorry, we can't get that information right now. Please try again later. If the problem continues, contact your helpdesk.
X-OWA-Error: ScriptLoadError;undefined
X-OWA-Version: undefined
X-FEServer: NETXSRV05
X-BEServer: undefined
Date: 02.01.1601 15:05:27

---------------------------

 

 

Fazit

> Exchange entfernen, in meinem jetzigen Fall Exchange 2013 ist nicht ganz ohne (alle Postfächer deaktiviert, inkl. die speziellen System Postfächer Und: letzten Endes einfach alle noch gestarteten Exchange von Hand gestoppt)

> Exchange 2013 auf dem gleichen Rechner (beherbergt auch certsrv IIS Webseite und ist für dessen Aufruf zuständig) mit gleichem Hostnamen zu installieren war vorerst auch nicht einfach so möglich, hierzu war doch recht Handarbeit notwendig (siehe den von mir oben geposteten Link)

> Endlich, als der Exchange 2013 installiert war, Probleme beim Einloggen mit dem Administrator Account via ECP Seite

Dies war erst möglich, als ich mich nicht via https://meinedomain.ch/ecp versucht habe einzuloggen, sondern als ich z.B. https://hostnameServer/ecp verwendet hatte (kam natürlich eine Zertifikats Warnmeldung)

 

Beim Einloggen, also beim ersten Versuch, nach erfolgreicher Exchange 2013 Installation mich via Administrator via ECP Seite anzumelden, versuchte ich dies ja via https://meinedomain.ch/ecp

 

Dazu möchte ich erwähnen ,dass dies mit dem alten Exchange 2013, also dem zuvor installierten Exchange ohne Probleme gelang, mit dem gleichen Zertifikat, von der gleichen, immer noch installierten PKI Zertifizierungsstelle (intern) Und: die virtuellen Verzeichnisse habe ich so angepasst, dass zumindest der Name meinedomain.ch im SAN Zertifkat als FQDN auch vorkommt (wie gesagt, mit diesem, immer noch auf dem IIS vorhandenen Zertifikat konnte ich mich zuvor auf dem alten Exchange ohne Probleme via OWA, ECP einloggen, obwohl auch schon da früher oder später diese Schannel Fehlermeldungen im, ja würde sagen, schon fast Sekundentakt auftauchten.

 

> Und zu guter letzte muss ich leider auch noch erwähnen, dass ich mich nach erfolgreichem Login via https://hostnameServer/ecp (mit Zertifikats Warnmeldung) zuerst die Augen reiben musste, warum?

 

Weil, warum auch immer, die angezeigte Sprache in Englisch war und nicht auf deutsch.

Bin mir ziemlich sicher, dass ich das gleiche ISO File schon vorher, für den alten Exchange 2013 verwendet hatte Und: nach dem damaligen ersten, erfolgreichen einloggen ich damals eine deutsche ECP Webseite zu Gesicht bekam, keine Englische, wie jetzt (ich weiss, man kann dies via OWA Webseite, da einloggen, unter den Optionen ändern)

 

Diese Schannel Fehlermeldungen nerven aber gewaltig!

 

Hat Jemand eine Erklärung, am Wichtigsten ist mir, dass ich mich wieder via ECP einloggen kann, ohne dass ich nach erfolgtem Login eine weisse Seite bekomme, hat mir Jemand hierzu eine Erklärung, warum ich nun mit diesem Problem zu kämpfen habe?

 

Hat mir Jemand eine Erklärung auf meine "viele" Phänomene überhaupt?

 

[NorbertFe 2.041]

Frisch installiert und dann alte Version? Aktuell ist seit dieser Woche cu6. Und bevor die Frage kommt - ja jedes cu ist die volle installation.

[andrew 15]

Zuerst hatte ich Exchange 2013 installiert, dies vor ein paar Monaten.

Diesen mit allen Windows Updates versorgt, Cu5 ebenfalls installiert.

 

Nun, seit kurzem hatte ich ja hier im Forum einen Beitrag betreffend Sophos WAF (Exchange 2013 schützen) hier gepostet - zu diesem Beitrag hattest Du auch Stellung genommen. Die OWA Seite wurde da nicht korrekt angezeigt, ich suchte nach einer Lösung. Dies kurz als Rückblick.

 

In Anbetracht dessen, dass meine interne Zertifizierungsstelle meiner Ansicht nach das Handling von Zertifikaten, das Ausstellen von SSL Zertifikaten sauber erledigt und ich bis vor kurzem noch keine Probleme hatte, wenn ich von dieser SSL Zertifikate (SAN) Zertifikate beantragt habe (Request, welche ich auf dem Exchange 20113 generiert hatte meiner internen CA eingereicht), verwundert mich nun folgendes:

 

Ich habe wie erklärt den irgend einmal gut laufenden Exchange 2013 SP1 (CU5) gestern deinstalliert und auf dem gleichen, virtuellen Server den Exchange 2013 SP1 wieder neu installiert, dies weil

> A: Wissen wollte, ob ich dann meine OWA Seite von extern sauber über/ durch meine Sophos UTM Firewall mit der aktivierten Sicherheitsfunktion WAF erreichen kann. Die Antwort darauf ist zurzeit: NEIN

> Auch beim nun nicht mehr vorhandenen, bereits platt gemachten Exchange 2013 hatte ich wie oben schon erwähnt unter anderem in der Ereignisanzeige (Quelle = Schannel, Ereignis-ID = 36888 Meldungen/ Warnmeldungen)

 

Aber der Hauptgrund für das Deinstallieren und erneute Installieren war schon, oder ist immer noch diese Sophos UTM WAF (Web Application Firewall)

Du siehst, mir ist es langweilig, darum opfere ich in meiner Zeit derart viel Zeit, um solche Dinge zu testen :-)

 

Bemerkung dazu:

Mit einem SBS 2008 (Exchange 2007) habe ich übrigens mit den praktisch gleichen Web Application Firewall Regeln (WAF) die OWA Seite von extern erreichen können, mich einloggen können, alles war wunderbar - nur eben mit diesem Exchange 2013 scheint mir das im Moment nicht gelingen zu wollen, das noch am Rande bemerkt, hat aber hier nichts direkt mit meinem Problembeschrieb zu tun.

 

Und: Ja, ich bin ergeizig und bin wie ein Bulldogge, wenn ich an ein Problem stosse, welches nicht gelöst werden kann, versuche ich solange nach einer Lösung zu finden (ich beisse mich in das Problem), bis ich hoffentlich meistens die passende Lösung gefunden habe :-)

 

Aber um das geht es hier ja gar nicht ;)

 

 

Fazit

> Aktuell Exchange 2013 SP1 mit CU5 installiert (CU6 installiere ich demnach noch nach)

> Nein, ich habe noch nicht alle Updates installiert, hole ich noch nach.

> Mein zwei Warnmeldungen in der Ereignisanzeige haben anscheinend etwas mit dem SSL Zertifikat zu tun. Dies vermute ich, weil wenn Du den Text der beiden Fehlermeldungen liest, stellst Du fest, dass irgendwo die Rede von Code 40 ist!

 

Gemäss dieser Seite hier, wenn ich diese als Referenz benutzen kann http://blogs.msdn.com/b/kaushal/archive/2012/10/06/ssl-tls-alert-protocol-amp-the-alert-codes.aspx

 

wäre Code 40 ein Handshake Problem in Bezug SSL Kommunikation.

Wie erwähnt, das angewendete SAN SSL Zertifikat ist

> A von meiner internen SubCA signiert worden

> B war vorher schon im Einsatz und hat beim ECP/ OWA keine Probleme verursacht, das Phänomen, das nach dem Einloggen via ECP Seite dann alles weiss war, war nicht vorhanden

> C das gleiche Zertifikat und generell von meiner internen SubCA verwendeten Zertifikate machen nun genau bei OWA, ECP Probleme, warum kann ich nicht nachvollziehen.

 

verwende ich nämlich das vom Exchange selbstsignierte Zertifikat, dann kann ich mich via https://hostnameExchange/ecp im ECP einloggen, bekomme nach dem Einloggen KEINE weisse Seite.

 

Spannend oder?

 

Ob da das Installieren von allen Windows Updates hilft?

Ich werde es bald Wissen, werde es im Verlauf des Tages noch herausfinden :-)

 

 

Ach ja: Was meinst Du mit: jedes CU ist die volle Installation?

[NorbertFe 2.041]

Nur fürs Verständnis sp1=cu4 also cu5 und cu6 muss man nicht nachinstallieren wenn man neuinstallieren. Absonsten käme ich nie auf die Idee einen Exchange zu deinstallieren und dann auf der selben Hardware nochmal eine ältere Version zu installieren. Eventuell solltest du solche Tests in einer etwa nachvollziehbareren Weise durchführen, denn zumindest ich kann dir inzwischen nicht mehr folgen, da das doch recht viel für ein Forum ist.

[andrew 15]

Ich verstehe folgendes NICHT:

 

Nochmals zu eurem Verstädnis, kurz und knackig erklärt (zusammengefasst)

 

Situation vorher:

> SSL SAN Zertifikat mit 3 Alternativen FQDN's

- outlook.it-netx.ch

- autodiscover.it-netx.ch

- exchange.it-netx.ch

 

auf Exchange 2013 installiert Und: ecp, owa, autodiscover, ALLES funktionierte mit diesem SAN Zertifikat!

 

 

Situation jetzt:

> Exchange 2013 auf virtuellem Server 2012 R2 mit Hostname NETXSRV05 platt gemacht

> Exchange 2013 auf virtuellem Server 2012 R2 mit Hostname NETXSRV05 neu aufgesetzt

 

Das gleiche, vorher im Einsatz gewesene SAN SSL Zertifikat wieder auf dem soeben frisch installierten Exchange 2013 implementiert

 

Und nun ist das Problem,

> dass beim Einloggen mit dem administrator Account via ecp Webseite eine weisse erscheint

 

Die Ereignisanzeige sagt dazu folgendes

--------------------------

Siehe dazu ganz am Anfang dieses eröffnetem Themas die Fehlermeldungem in der Ereignisanzeige

--------------------------

 

> und ebenfalls verstehe ich NICHT, dass OWA auch nicht funktioniert (Fehlermeldung habe ich weiter oben schon geschildert)

 

Es scheint, als würde das vorher wunderbar funktionierende SSL SAN Zertifikat auf dem soeben frisch installierten Exchange 2013 Server NICHT mehr richtig funktionieren?!

 

Denn ich erhalte ja wie erklärt nach dem Anzeigen der ECP Webseite (und dies ohne Zertifikats Warnmeldungen) und danach nach erfolgreichem Login mit dem Administrator Account eine weisse Seite angezeigt.

 

Die Tatsache, dass wenn ich ein neues, selbsigniertes Exchange Zertifikat direkt auf dem Exchange erstelle, funktioniert die ecp Verwaltungsseite?!

 

Tatsache ist ebenfalls, dass ich wissentlich NICHTS an meiner internen PKI infrastruktur geschraubt habe und trotzdem scheint es so, dass der soeben frisch installierte Exchange mit meinen beteits virhandenen oder auch neu via PKI erstellten Zertifikaten NICHT klar kommt?!

 

Wieso NICHT?

Wieso konnte ich vorher für ECP, OWA usw. diese Zertifikate problemlos verwenden und nun nicht mehr?

 

Was ist in Bezug SSL auf einem neu, ungepatchten Exchange 2013 SP1 da anders?

Es sieht so aus, sofern ich die Fehler in der Ereignisanzeige richtig interpretiere, dass der Exchange mit irgen etwas, was im SSL SAN Zertifikat enthalten ist, nicht klar kommt und darum tonnenweise Schannel Fehlermeldumgem geloggt werden Und: nach dem Einloggen via ECP Webseite ich darum eine weisse Seite zu Gesicht bekomme?!

 

Das ist mein Problem, warum ich nun mit einer solchen Situation mich beschäftigen darf/ muss?

Wenn ich einen Exchange platt mache, auf dem gleichen virtuellen Host wieder einen Exchange 2013 frisch aufsetze, sollte ich doch die vorhandenen SSL SAN Zertifikate wieder verwenden können oder nicht?

 

In meinem Fall scheint dies NICHT der Fall zu sein!

Was könnte der Grund sein?

[NorbertFe 2.041]

Hat deine starke und wiederholte Betonung des Wortes "nicht" irgendeine tiefere Bedeutung?

[andrew 15]

nein, das Wort "nicht", welches ich ggf. öfters als "normal" hier benutzt habe, hat keine tiefere Bedeutung :-)

 

Was sagst Du nun zu meiner Auslegung und Zusammenfassung meines Problems, meiner doch nun ziemlich genau geschilderten Problemstellung?

Eine Idee Norbert und/ oder Jemand anderes hierfür eine Erklärung oder noch besser, eine Lösung? ;-)

 

Danke für das oder die konstruktive(n) Feedback(s) *smile*

[NorbertFe 2.041]

Es ist also ein Zertifikat deiner eigenen ca? Stell dir doch mal ein neues aus. Obwohl ich da selbst nicht wirklich dran glaube. Aber so oder so, würde ich an deiner Stelle nicht mehr mit sp1 rumtesten. Spätestens in 3-4 Monaten ist das unsupported.

 

Bye

Norbert

[andrew 15]

Habe soeben mich daran gemacht, das CU6 zu downloaden und installieren.

Unter dem Punkt "Probleme, die behoben werden" gibt es eine sehr interessante Zeile, ziemlich weit unten in dieser, doch eher langen Liste (da musste Microsoft wieder viel nachbessern, dass die Liste so lange ausfällt) :-)

 

Ein Problem, was mit CU 6 für Exchange 2013 behoben wird lautet:

"2971270 Leere Seite nach der Anmeldung an Exchange Server 2013 BK (ehemals ECP)"

 

Was sagt mir das?

Vollgas CU6 installieren, um genau dieses Problem nun zu beheben Und: Vielleicht sind dann auch die tonnenweise vielen Schannel Meldungen in der Ereignisanzeige weg, wer weiss? :-)

 

NEWS folgen selbstverständlich, as soon, as possible

[NorbertFe 2.041]

Ja genau das Versuch ich dir die ganze Zeit zu sagen.

[zahni 554]

Ich würde mir mal den Signaturalgorithmus und die Schlüssellänge der Zertifikate anschauen. Was ist dort ausgewählt?

Kenne Exchange  nicht, ich würde es  aber mal mit SHA1RSA/2048Bit probieren.

[andrew 15]

> Der Signaturalgorithmus ist sha512RSA

> Schlüssellänge des Öffentlichen Schlüssels ist RSA (2048 Bits)

 

Effektiv könnte hier das Problem gelegen haben, dass nach dem Anmelden via ECP Admin Seite eine weisse Seite erschien, weil Server 2012 (und R2) anscheinend auch noch nicht SHA512 unterstützt, was mich sehr, sehr verwundert. Ob der Grund wohl wirklich nur bei der ggf. "hohen Rechenleistung" liegt, welche durch das Verschlüsseln dadurch entsteht?

 

Dazu habe ich noch folgende spannende Artikel gefunden:

http://www.frankysweb.de/windows-mobile-6-0x80072f0d/ (hier werden Probleme mit Windows Mobile gezeigt, wenn der Hashalgorithmus beim Erstellen einer internen PKI SHA512 gewählt wird)

Beim Erstellen einer internen PKI folgt beim Punkt Privater Schlüssel/ Kryptografie der Punkt: "Geben Sie die Kryptografie Optionen an"

Hier hatte ich übrigens SHA512 gewählt und mein Root Zertifikat mit RSA (4096 Bits) erstellt

Der Franky hatte hier beim ersten Mal, als er seine PKI erstellt hat, auch nicht SHA1 sondern gleich SHA512 verwendet Und: Hatte eben wie soeben im Link zu lesen ist, anscheinend mit Windows Mobile Geräten Problemen, dass diese wiederum anscheinend mit einem solchen "hohen" Hashalgorithmus nicht kompatibel waren oder vielleicht immer noch nicht sind?!

 

Oder hier, Probleme mit Lync

http://social.technet.microsoft.com/Forums/windowsserver/en-US/857c6804-8ce1-4f09-b657-00554055da16/tls-12-and-sha512?forum=winserversecurity

 

Da hat er in der internen PKI auch als Hashalgorithmus SHA512 und nicht SHA1, nicht SHA256, nicht SHA384 verwendet (die Schüssellänge weiss ich nicht oder habe ich im Artikel vielleicht übersehen, welche er verwendete)

 

Er respektive seine Firma geriet wurde dadurch auch mit unerwünschten Effekten, Problemen konfrontiert, ich zitiere einen Teil davon:

-------------------

Lync 2013 is an example:

Microsoft TechNet: Lync 2013 Certificate Infrastructure Requirements SHA512 support is on the list.

Real world examples with SHA512:

SChannel Errors on Lync Server Preventing Client Logon
Lync Front End Server not starting because of certificate issue

Well and this one I just discovered:

Lync 2013 client cannot connect to the lync pool!

-------------------

 

Ansonsten, wenn es Jemanden interessieren sollte, den ganzen Artikel nehmen und ggf. dazu ein Kaffee geniessen, vielleicht in der Pause oder so :-)

 

zu meinem Problem hier, dass ich ja nach dem Einloggen via https://meinedomain.ch/ecp dann eine weisse Seite zu Gesicht bekam, hat schlussendlich wohl das kumulative Update CU6 und ggf. noch die paar wenigen, restlichen Windows Updates (ca. 33 an der Zahl) geholfen.

 

Tatsache war, dass gerade nach dem Aufspielen des CU6 und einem Neustart des Exchange 2013 und dem erneuten Testen via ECP Seite (ob noch weisse Seite kommen, nach Login) wieder die weisse Seite erschienen war.

 

Komisch war dann aber, als ich mich dann via OWA einloggte (weiss nicht mehr, ob ich dies auch mit dem Administrator tat) oder zuerst gleich mit einem 0815 Account OWA testete, klappte das Login via OWA.

 

Denn dies war vor dem Einspielen des CU6 auch nicht der Fall, obwohl OWA per Standard für jeden Benutzer freigeschaltet ist Und: der 0815 Benutzer selbstverständlich auch über ein Postfach verfügt :-)

 

nach diesem erfolgreichen Login via OWA klappe dann interessanterweise auch das Login via ECP :-)

 

Jedoch kämpfe ich nach wie vor mit Schannel Fehlermeldungen, obwohl ich dem Exchange Server, also dem darunter liegenden OS (Server 2012 R2) beigebracht habe, dass es nun auch SHA512 als Hashalgorithmus kennen und akzeptieren soll, dies obwohl ich genau wie im diesem Artikel hier http://www.michaelm.info/blog/?p=1273  einen bzw. beide Registrierungsschlüssel ergänzt habe

> RSA/SHA512

> ECDSA/SHA512

 

Das nun nach wie vor Schannel Fehlermeldungen erscheinen, ist mir nicht klar. Naja, wenigstens klappt nun OWA, ECP (keine weisse Seite mehr) Und: Ich muss nicht meine PKI Rolle deinstallieren und neu installieren, denn den Hashalgorithmus kann man nicht einfach so schnell, schnell bei einer PKI ändern.

 

Bei mir ist ja alles in einem Labor, da ist das ja nicht so tragisch, aber in einer Firma würde dies wieder ganz anders aussehen (inkl. Konsequenzen)

Zumal SHA1 ja längstens geknackt wurde und steinalt ist, verstehe ich nicht, warum beispielweise bestimmte Mobile Geräte, ja sogar der Server 2012R2 SHA512 per Standard nicht implementiert hat

 

denn sha512 kann sogar, gemäss diesem Artikel hier auch Performance Gewinne bringen, siehe hier: https://community.emc.com/community/edn/rsashare/blog/2010/11/01/sha-2-algorithms-when-sha-512-is-more-secure-and-faster

 

P.S.

Norbert, ja sogar funktioniert nun Sophos UTM mit WAF (Web Application Firewall) für meinen Exchange 2013 (OWA), jedoch ActiveSync nicht (oder noch nicht, muss noch üben und auch hier noch den Fehler finden)

[Daniel -MSFT- 129]

Wenn Du mit 'bestimmte mobile Geräte' Windows Mobile meinst, dann sei angemerkt, dass die Weiterentwicklung davon komplett eingestellt ist seit längerem und schon mehrere Nachfolgeversionen draussen sind - Windows Phone schon mal gehört?

bearbeitet 31. August 2014 von Daniel -MSFT-

[andrew 15]

Von Windows Phone habe ich schon gehört, aber nur gehört - besitze keines :-) (noch nicht)

Vielen Dank für die Links

 

Betreffend http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx

Im Titel steht SHA2 and Windows, jedoch ist da leider das neuste OS Server 2012 bzw. Server 2012R2 mit welchem auch ich per Zufall hier Probleme in Bezug auf Schannel Fehlermeldungen in der Ereignisanzeige geschildert habe nicht aufgeführt!

 

Frage

Hast du mir einen aktuellen Post, wo aktuelle OS und deren SHA2 Kompatibilität (bzw. Hashalgorithmus SHA512) aufgezeigt werden?

 

Auch der zweite Link von Dir ist nicht viel neuer, stammt aus dem Jahre 2011. Da ist die Rede von Windows XP, welches seit kurzem nicht mehr supportet wird oder von Server 2003

 

Hast Du meinen Beitrag gelesen und per Zufall mitbekommen, auf welchem System mein Exchange 2013 läuft?

auf keinem der hier genannten OS, welche in deinen beiden Links sind!

 

Aber danke dennoch und eben, wenn Du noch was betreffend SHA2 Kompatibilität (bzw. Hashalgorithmus SHA512) für Server 2012 und Server 2012 R2 hast, würde ich mich extrem freuen, Du bist ja an der Quelle, wenn Du verstehst was ich meine :-)

[Daniel -MSFT- 129]

Das nun nach wie vor Schannel Fehlermeldungen erscheinen, ist mir nicht klar. Naja, wenigstens klappt nun OWA, ECP (keine weisse Seite mehr) Und: Ich muss nicht meine PKI Rolle deinstallieren und neu installieren, denn den Hashalgorithmus kann man nicht einfach so schnell, schnell bei einer PKI ändern.

 

Das kann daran liegen, dass ein Fallback auf ein anderes Verschlüsselungsverfahren erfolgt. TLS 1.2 ist ja optional, wenn das nicht klappt, dann erfolgt ein Fallback auf ältere Versionen mit anderen Ciphern.

 

Zumal SHA1 ja längstens geknackt wurde und steinalt ist, verstehe ich nicht, warum beispielweise bestimmte Mobile Geräte, ja sogar der Server 2012R2 SHA512 per Standard nicht implementiert hat

 

Vorsicht mit solchen Pauschalaussagen. Angriffe auf SHA-1 sind bisher akademisch - in der Praxis stellen sich da noch gewaltige Hürden auf. Außerdem ist SHA-2-Support im Server schon lange integriert und sogar zurückportiert bis Windows XP und Windows Server 2003. Das hilft aber nicht, wenn die Anwendung zum Beipsiel nicht mit SHA-2 umgehen kann. SHA-512 ist auch unter Windows 8.1 und Server 2012 R2 unterstützt, aber standardmäßig nicht aktiviert. Es kann aber über einen Registry-Eintrag oder http://support.microsoft.com/kb/2973337/en-us aktiviert werden. 

 

Auf die beiden älteren Artikel habe ich oben verwiesen, weil dort erklärt ist, dass es nicht nur auf das OS selbst ankommt sondern auf die komplette Implementierung aller beteiligten Softwarekomponenten von Client und Server, die die verwendete SHA-Version und Cipherstärke unterstützen müssen.

 

denn sha512 kann sogar, gemäss diesem Artikel hier auch Performance Gewinne bringen, siehe hier: https://community.emc.com/community/edn/rsashare/blog/2010/11/01/sha-2-algorithms-when-sha-512-is-more-secure-and-faster

 

Lies den Artikel mal genauer. Nicht nur einzelne Brocken herauspicken ;-) Da wird sehr stark differenziert, wann das tatsächlich sinnvoll ist. Bei asymmetrischen Operationen ist die Auswirkung nahe null. Die Interoperabilität kann aber problematisch sein. SHA-256 in der CA als Default zu verwenden, wäre sinnvoller. Schau mal zum Vergleich: Selbst moderne Browser haben TLS 1.2 erst seit kurzem auf ihrer Liste der Funktionen. Google Chrome verfügt über TLS 1.2 seit Version 30, Opera seit Version 17, Firefox aktiviert TLS 1.2 in Version 27 und im Internet Explorer ist es seit Version 11 standardmäßig aktiviert.

 

Heraufstufen auf SHA-512 kannst Du es später ja, wie hier für SHA-256 beschrieben: http://blogs.technet.com/b/pki/archive/2013/09/19/upgrade-certification-authority-to-sha256.aspx oder http://social.technet.microsoft.com/Forums/windowsserver/en-US/91572fee-b455-4495-a298-43f30792357e/is-it-possible-to-change-the-hash-algorithm-when-i-renew-the-root-ca oder http://blogs.dirteam.com/blogs/robing/archive/2013/11/21/lync-front-end-server-not-starting-because-of-certificate-issue.aspx

 

Have fun!
Daniel

bearbeitet 1. September 2014 von Daniel -MSFT-