Freigeben über

Änderungen an der Überprüfung des TLS-Server-Zertifikats im Microsoft Edge-Browser

  • Artikel

Wenn Microsoft Edge Verbindungen mit einem HTTPS-Server herstellt, überprüft Edge, ob der Server ein Zertifikat vorgelegt hat, das von einer Vom Browser vertrauenswürdigen Entität ausgestellt wurde. Diese Vertrauensstellung wird über eine Zertifikatvertrauensliste hergestellt, und die komponente, die für die Durchführung der Überprüfungen verantwortlich ist, wird als Zertifikatüberprüfung bezeichnet.

In früheren Versionen von Microsoft Edge wurden sowohl die Standardzertifikatvertrauensliste als auch die Zertifikatüberprüfungslogik von der zugrunde liegenden Betriebssystemplattform bereitgestellt.

Für verwaltete Geräte werden ab Microsoft Edge 112 unter Windows und macOS sowohl die Standardzertifikatvertrauensliste als auch die Zertifikatüberprüfung vom Browser bereitgestellt und mit diesem ausgeliefert. Dieser Ansatz entkoppelt die Liste und die Überprüfung für das Standardüberprüfungsverhalten vom Stammspeicher des Hostbetriebssystems. Weitere Informationen zum Zeitpunkt der Änderung finden Sie in der Rolloutzeitachse und im Testleitfaden .

Auch nach der Änderung fragt der Browser die zugrunde liegende Plattform nach lokal installierten Stammelementen ab, die von Benutzern und/oder Unternehmen installiert wurden. Daher sollten Szenarien, in denen ein Benutzer oder Unternehmen mehr Stammelemente im Stammspeicher des Hostbetriebssystems installiert hat, weiterhin funktionieren.

Diese Änderung bedeutet, dass die Zertifikatüberprüfungslogik in Microsoft Edge unter Windows und macOS konsistent funktioniert. In einem zukünftigen Release gilt der Rollout auch für Linux und Android. Aufgrund der Apple App Store-Richtlinien werden der von Apple bereitgestellte Stammspeicher und die Zertifikatüberprüfung unter iOS und iPadOS weiterhin verwendet.

Standardquelle der Zertifikatvertrauensliste

Der Stammspeicher, der im Lieferumfang von Microsoft Edge unter Windows und macOS enthalten ist, stammt aus der Zertifikatvertrauensliste (Certificate Trust List, CTL), die vom Microsoft-Programm für vertrauenswürdige Stammzertifikate definiert wird. Dieses Stammzertifikatprogramm definiert die Liste, die im Lieferumfang von Microsoft Windows enthalten ist. Daher sollten Kunden erwarten, dass keine vom Benutzer sichtbaren Änderungen angezeigt werden.

Wenn unter macOS ein Zertifikat ausgestellt wird, das von einem Stammzertifikat ausgestellt wird, dem die Plattform, aber nicht das Microsoft-Programm für vertrauenswürdige Stammzertifikate vertraut, ist das Zertifikat nicht mehr vertrauenswürdig. Es wird nicht erwartet, dass dieser Mangel an Vertrauenswürdigkeit eine häufige Situation ist, da die meisten Server bereits sicherstellen, dass die von ihnen verwendeten TLS-Zertifikate von Microsoft Windows als vertrauenswürdig eingestuft werden.

Updates werden im Rhythmus veröffentlicht, der in den Versionshinweisen für das Microsoft Trusted Root Program dokumentiert ist.

Rolloutzeitplan und Testleitfaden

Ab Microsoft Edge 109 stehen eine Unternehmensrichtlinie (MicrosoftRootStoreEnabled) und ein Flag in edge://flags ("Microsoft Root Store") zur Verfügung, um zu steuern, wann der integrierte Stammspeicher und die Zertifikatüberprüfung verwendet werden.

Geräte, die nicht vom Unternehmen verwaltet werden, erhielten das Feature über einen kontrollierten Featurerollout (Controlled Feature Rollout, CFR) in Microsoft Edge 109 und erreichten 100 % der nicht verwalteten Geräte in Edge 111. Weitere Informationen finden Sie unter Microsoft Edge-Konfigurationen und Experimente. Darin wird erläutert, wie CFRs in Microsoft Edge funktionieren. Für unternehmensverwaltete Geräte wurde die vorhandene plattformbasierte Implementierung über Microsoft Edge 111 verwendet.

Ab Microsoft Edge 112 wurde die Standardeinstellung für alle Windows- und macOS-Geräte geändert, einschließlich unternehmensverwalteter Geräte, um die im Browser ausgelieferte Verifiziererimplementierung und CTL zu verwenden. Die MicrosoftRootStoreEnabled-Richtlinie ist in dieser Version weiterhin verfügbar, damit Unternehmen das vorherige Verhalten wiederherstellen können, wenn unerwartete Probleme gefunden werden, und die Probleme an Microsoft melden können.

Microsoft empfiehlt Unternehmen mit Unterbrechungs- und Überprüfungsproxys oder anderen Szenarien mit TLS-Serverzertifikaten, die von Stammzertifikaten ausgestellt wurden, die sich nicht in der Microsoft-CTL befinden, um Kompatibilitätsprobleme proaktiv zu identifizieren und Microsoft zu melden.

In Microsoft Edge 115 wird die Unterstützung für die MicrosoftRootStoreEnabled-Richtlinie entfernt.

Bekannte Unterschiede beim Verhalten von lokal vertrauenswürdigen Zertifikaten unter Windows

Strengere RFC 5280-Konformität

Die neue, integrierte Zertifikatüberprüfung ist bei der Durchsetzung von RFC 5280-Anforderungen strenger als die alte plattformbasierte Überprüfung.

Beispiele für eine strengere RFC 5280-Konformität sind:

  1. Algorithmusparameter für ECDSA-Algorithmen müssen fehlen. Die alte Überprüfung würde die Parameter ignorieren, während die neue das Zertifikat ablehnt. Weitere Informationen finden Sie unter Chromium-Problem 1453441 weitere Informationen.
  2. Namenseinschränkungen, die eine IP-Adresse angeben, müssen acht Oktette für IPv4-Adressen und 32 Oktette für IPv6-Adressen enthalten. Wenn Ihr Zertifikat eine leere IP-Adresse angibt, sollten Sie das Zertifikat erneut ausstellen und die Einschränkung des IP-Adressnamens vollständig weglassen.
  3. Namenseinschränkungen mit einer leeren "ausgeschlossenen" Liste sind ungültig. Die Windows-Zertifikatanzeige zeigt diese Liste als Excluded=None in den Name Constraints Details an. Weitere Informationen finden Sie unter Chromium-Problem 1457348 weitere Informationen. Anstatt eine leere Liste anzugeben, lassen Sie sie vollständig aus.

Bekannte Unterschiede beim Verhalten der Sperrüberprüfung unter Windows

Zusätzlich zu den strengeren RFC 5280-Anforderungen unterstützt die neue Überprüfung keine LDAP-basierten Zertifikatsperrlisten-URIs (Certificate Revocation List, CRL).

Wenn Ihr Unternehmen die RequireOnlineRevocationChecksForLocalAnchors-Richtlinie aktiviert und die CRLs gemäß RFC 5280 ungültig sind, werden in Ihrer Umgebung möglicherweise Fehler und/oder ERR_CERT_UNABLE_TO_CHECK_REVOCATION angezeigtERR_CERT_NO_REVOCATION_MECHANISM.

Wenn sie feststellen ERR_CERT_NO_REVOCATION_MECHANISM, sollten Sie bestätigen, dass die Zertifikatsperrliste an dem durch das Zertifikat angegebenen URI eine DER-codierte (nicht PEM-codierte) Antwort zurückgibt.

Weitere Informationen