![\"Edge\"](\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2020\/01\/Edge.jpg\" "\\"Edge\\"")
[English]Die besten Geschichten schreibt immer noch das Leben. Heute ein \"What the Fuck\" (WTF) eines Microsoft-Mitarbeiters, der gerade \u00fcber den Sachverhalt gestolpert ist, dass die Edge-Entwickler die Verifikation von TLS-Zertifikaten ab der Edge-Version 110 vom Host entkoppelt haben. Auf das Thema hatte ich Mitte Februar hier im Blog bereits hingewiesen.<\/p>\n
<\/p>\n
In seinem WTF verweist er auf einen Abschnitt Known revocation checking behavior differences on Windows<\/a> zum Edge Supportbeitrag Changes to Microsoft Edge browser TLS server certificate verification<\/a>. In obigem Tweet schreibt er: <\/p>\n Ich bin beunruhigt. Verwendet Edge nicht mehr dieselbe Zertifikatswiderrufs-Engine wie Windows? Wie kann das in Unternehmensumgebungen nicht zu einem absoluten Blutbad f\u00fchren? (Vor allem in Bezug auf LDAP CRLs, die Intranetseiten von Unternehmen DEFINITELY STILL USE)<\/p>\n<\/blockquote>\n Im betreffenden Support-Artikel hei\u00dft es, dass die neue, (wohl in Edge) integrierte Zertifikats\u00fcberpr\u00fcfung strenger bei der Durchsetzung der RFC 5280-Anforderungen f\u00fcr Zertifikatsperrlisten (CRLs) ist als die alte, (in Windows implementierte) plattformbasierte \u00dcberpr\u00fcfungsfunktion. Au\u00dferdem unterst\u00fctzt die neue Pr\u00fcfstelle keine LDAP-basierten CRL-URIs. Weiterhin hei\u00dft es: <\/p>\n Wenn ein Unternehmen die Richtlinie RequireOnlineRevocationChecksForLocalAnchors <\/em>aktiviert und die CRLs nicht gem\u00e4\u00df RFC 5280 g\u00fcltig sind, kann es in Ihrer Umgebung zu den Fehlern ERR_CERT_NO_REVOCATION_MECHANISM und\/oder ERR_CERT_UNABLE_TO_CHECK_REVOCATION kommen.<\/p>\n Wenn ERR_CERT_NO_REVOCATION_MECHANISM auftritt, sollten Sie sich vergewissern, dass die CRL an dem vom Zertifikat angegebenen URI eine DER-kodierte (nicht PEM-kodierte) Antwort zur\u00fcckgibt.<\/p>\n Wenn ERR_CERT_UNABLE_TO_CHECK_REVOCATION-Fehler auftreten, sollten Sie sich vergewissern, dass der Zertifikatsaussteller auch der CRL-Aussteller ist, das cRLIssuer-Feld des Zertifikats nicht gesetzt ist und der URI, der die CRL hostet, das HTTP-Protokoll verwendet. Riecht irgendwie nach \u00c4rger, den auch Ryan Ries heraufziehen sieht.<\/p>\n<\/blockquote>\n Interessant scheint mir auch die Diskussion auf Twitter<\/a> zu sein, wo angedeutet wird, dass das Ganze auf eine Entscheidung des Chromium-Teams zur\u00fcck geht (und die Edge-Entwickler h\u00e4ngen da dran). <\/p>\n Dass Schwierigkeiten zu erwarten seien, hatte ich im Januar im Beitrag Edge 109.0.1518.49<\/a> bereits angedeutet. Microsoft hatte eine \u00c4nderung in der Verifizierung von TSL bekannt gegeben. Dort hie\u00df es unter \"\u00c4nderungen bei der TLS-Server-Zertifikats\u00fcberpr\u00fcfung\":<\/p>\n In Microsoft Edge Version 110 werden die Zertifikatsvertrauensliste und die Zertifikats\u00fcberpr\u00fcfung vom Root Store des Host-Betriebssystems entkoppelt.<\/p>\n Stattdessen werden die Standard-Zertifikatsvertrauensliste und die Zertifikats\u00fcberpr\u00fcfung vom Browser bereitgestellt und mit diesem ausgeliefert. <\/p>\n Die Richtlinie MicrosoftRootStoreEnabled <\/em>ist jetzt zum Testen verf\u00fcgbar, um zu steuern, wann der integrierte Root Store und die Zertifikats\u00fcberpr\u00fcfung verwendet werden. Es ist geplant, die Unterst\u00fctzung f\u00fcr diese Richtlinie in Microsoft Edge Version 111 zu entfernen.<\/p>\n<\/blockquote>\n Und dann gab es nochmals im Februar 2023 den Blog-Beitrag \u00c4nderungen im Edge: \u00c4nderung bei TLS-Zertifikaten, kein Uninstall mehr, Server 2012\/R2-Support<\/a> wo ich einen Hinweis eines Lesers aufgegriffen hatte, der mir dazu schrieb:<\/p>\n Hi \u2013 hast ja mitbekommen dass der Edge jetzt das Verhalten bei den RootCa \u00e4ndert. In Zukunft schaut er erst mal bei der MS nach, ob das RootCert g\u00fcltig ist, und wenn da nichts ist erst in den lokalen Speicher f\u00fcr RootCa Zerts. <\/p>\n Das bedeutet aber dass der Admin die Macht verliert, selber \u00fcber die RootCa Certs zu entscheiden. Machen auch heute die wenigsten und lassen die RootCas von MS patchen, aber manchen mag das \u00c4rgern. Beh\u00f6rden z.B. [\u2026]<\/p>\n<\/blockquote>\n Der Leser meinte, dass er in der Praxis noch keinen Administrator getroffen habe, der sich klar war, wo die RootCa Certs herkommen, bzw. nachgedacht hat. Frage: Ist das Thema bei euch auf dem Radar? Werden Probleme erwartet oder sind bereits welche aufgetreten? Ich kann das Thema TLS-Zertifikatsverifikation im Edge aktuell noch nicht so richtig absch\u00e4tzen. <\/p>\n","protected":false},"excerpt":{"rendered":" [English]Die besten Geschichten schreibt immer noch das Leben. Heute ein \"What the Fuck\" (WTF) eines Microsoft-Mitarbeiters, der gerade \u00fcber den Sachverhalt gestolpert ist, dass die Edge-Entwickler die Verifikation von TLS-Zertifikaten ab der Edge-Version 110 vom Host entkoppelt haben. Auf das … Weiterlesen Ich bin die Tage auf einen Tweet von Ryan Ries gesto\u00dfen, den ich mir sofort als Perle \"aufgehoben\" habe. Joseph Ryan Ries ist Windows Escalation Engineer bei Microsoft und ackert im Bereich Active Directory und Coding in diesem Unternehmen. Ries ist wohl die Tage auf einen Microsoft Supportbeitrag gesto\u00dfen, der ihn zu folgendem Tweet<\/a> veranlasst hat.<\/p>\n
![\"Edge](\"https:\/\/i.imgur.com\/KSiHCmS.png\"\/ "\\"Edge")
<\/a><\/p>\n\n
\n
Hinweise auf das Thema hier im Blog<\/h2>\n
\n
\n