Applies to: SSL-Zertifikate

SSL-Zertifikate Hilfe

Wir haben die Seite für Sie so gut wie möglich übersetzt. Sie können sie sich aber auch auf Englisch ansehen.

Warum entfernt GoDaddy die ClientAuth-EKU und wechselt zur DV-TLS-Ausgabe zur R1-Stammhierarchie?

Hinweis: Wenn bei Ihnen oder Ihren Kunden Fehler "nicht vertrauenswürdige Stammdaten" oder die Zertifikatkette angezeigt werden, lesen Sie unsere Schritte zur Behebung des Problems .

Ab dem 15. Juni 2026 dürfen öffentlich vertrauenswürdige SSL / TLS-Zertifikate, die für die Serververwendung ausgestellt wurden, nicht mehr die erweiterte Schlüsselverwendung „Clientauthentifizierung“ (EKU: clientAuth) enthalten. Hier sind die wichtigsten Punkte zu verstehen:

  • Die Änderung ist Teil der Aktualisierung des Chrome-Root-Programms: Neue Zertifikate dürfen nur die EKU „Serverauthentifizierung“ enthalten.
  • Neue öffentliche Zertifikate, die nach diesem Datum ausgestellt werden und clientAuth enthalten, werden von Chrome nicht als vertrauenswürdig eingestuft.
  • Zertifikate, die vor dem 15. Juni 2026 mit clientAuth ausgestellt wurden, sind von dieser Änderung nicht betroffen und bleiben bis zu ihrem Ablauf oder ihrem Widerruf gültig.
  • Zertifikate von privaten Zertifizierungsstellen (für den internen Gebrauch) sind von dieser Änderung nicht betroffen & mdash; sie gelten nur für öffentlich vertrauenswürdige Zertifikate.

Kurz gesagt: Wenn Ihre Organisation öffentliche TLS-Zertifikate für die Clientauthentifizierung (über die clientAuth-EKU) verwendet, müssen Sie bis zum 15. Juni 2026 handeln. Für die standardmäßige TLS-Nutzung von Websites (nur Serverauthentifizierung) erfordert diese Änderung keine Maßnahmen. Sie sollten jedoch rechtzeitig daran erinnert werden, Ihr Nutzungszertifikat zu prüfen, Funktionen entsprechend zu trennen und sicherzustellen, dass Sie mit dem sich entwickelnden Vertrauensmodell in Einklang stehen.

Wie wird GoDaddy diese Änderung umsetzen?

Bei unseren derzeitigen G2-Zwischenhändlern zur Signierung / Ausgabe ist keine EKU aufgeführt, sodass diese Hierarchie nicht den Anforderungen des Chrome-Root-Programms entspricht. Infolgedessen muss die Ausgabe der betroffenen G2-Zwischenprodukte bis zu diesem Datum eingestellt werden.

Anstatt neue Zwischenprodukte für die G2-Kette zu schaffen - & mdash; die voraussichtlich im April 2027 bei Google ablaufen / enden - & mdash; verschieben wir die DV-Ausgabe in unsere neue R1-Hierarchie, um die künftigen Richtlinieneinschränkungen zu erfüllen.

Wir ändern die öffentliche DV-Ausstellungskette, so dass neue DV-Leaf-Zertifikate aus der Hierarchie von GoDaddy TLS Root CA - R1 ausgestellt werden, wobei die GoDaddy TLS Intermediate CA DV - R1v1 ausstellende CA-ZertifikateCOMCOMANY_URL verwendet werden. Dies bedeutet, dass sich die von Servern bereitgestellte Emittenten-Kette (Leaf + Intermediate) möglicherweise von der bisherigen Historie einiger Systeme unterscheidet, und alle internen Tools, die einen bestimmten Legacy-Namen oder eine Kettenreihenfolge voraussetzen, müssen aktualisiert werden, damit sie die neue R1-Kette akzeptieren.

Darüber hinaus enthalten über diese Hierarchie ausgestellte Leaf-Zertifikate keine ClientAuth-EKU. Alle Workflows, die DV-Leaf-Zertifikate für die TLS-Clientauthentifizierung verwenden konnten, müssen zu einem geeigneten Zertifikatprofil / PKI-Pfad migriert werden. Während des Rollouts bleiben Zertifikate in Browsern funktionsfähig, da Clients mithilfe des in unserem Repository veröffentlichten erforderlichen kreuz signierten Vertrauenspfads R1 → G2 validieren (certs.godaddy.com).

So bleiben Zertifikate während der Umstellung von R1 im Browser funktionsfähig (Vorzeichen von R1 → G2)

Da wir die öffentliche DV-TLS-Ausgabe in die R1-Hierarchie migrieren, wird der R1-Stamm noch immer weitgehend vertrauenswürdig / vertrauenswürdig in Browser- und Betriebssystem-Truststores verteilt. Damit neu ausgestellte R1-Zertifikate in Browsern sofort funktionieren, setzen wir auf einen cross-signierten Vertrauenspfad zurück zum bereits vertrauenswürdigen G2-Root.

In der Praxis wird das Einzelblattzertifikat unter der ausstellenden Zertifizierungsstelle R1 DV ausgestellt. Die Kunden validieren es jedoch, indem sie eine Kette zu GoDaddy Klasse 2 Root - G2 aufbauen, indem sie das veröffentlichte Querformat R1 → G2 verwenden. Die relevanten Artefakte im Repository sind der G2-Vertrauensanker (gdroot-g2), das Gegenzertifikat (gd_tls_root-r1-cross-g2), das R1 DV ausstellende Zwischenprodukt (gd_tls_issuing_dv-r1v1) und der Stamm der nativen Hierarchie (gd_tls_root-r1) ) certs.godaddy.com. Dieser signierungsübergreifende Ansatz ermöglicht es Browsern, die Kette heute zu validieren (Verankerung bei G2), während sich die Vertrauensstellung von R1 im Laufe der Zeit ausbreitet.
r1 - g2 Kreuzweg

Warum wird diese Änderung vorgenommen?

Es gibt mehrere Gründe dafür, sich von Zertifikaten abzuwenden, die sowohl serverAuth als auch clientAuth unterstützen (auch als Zertifikate mit gemischten Verwendungszwecken bezeichnet):

  • Durch die Trennung von Serverauthentifizierung und Clientauthentifizierung wird das Zertifikatvertrauensmodell vereinfacht.
  • Verbesserte Sicherheitshygiene: Zertifikate mit zu vielen Zwecken erhöhen das Risiko (Missbrauch von clientAuth auf unbeabsichtigte Weise).
  • Die Verwendung dedizierter PKI-Hierarchien für bestimmte Funktionen trägt dazu bei, klarere Vertrauensgrenzen aufrechtzuerhalten und sich an allgemeinere Best Practices der PKI (Public Key Infrastructure) anzupassen.

Welche Vorteile hat diese Änderung?

  • Reduziertes Risiko durch Mehrzweckzertifikate: Indem Sie öffentliche Zertifikate auf serverAuth beschränken, wird die Angriffsfläche reduziert und die Vertrauensgrenzen sind klarer.
  • Bessere Compliance & Governance: Organisationen haben eine klarere Trennung zwischen Server- und Clientauthentifizierung, wodurch eine bessere Überwachung und Zertifikatlebenszyklusverwaltung unterstützt wird.
  • Verbesserte betriebliche Übersichtlichkeit: Wenn die clientAuth-Funktionalität in entsprechende Zertifikate oder Infrastrukturen aufgeteilt wird, ist es einfacher, Rollen, Widerrufe und Verlängerungen zu verwalten und sicherzustellen, dass das richtige Zertifikat für den richtigen Zweck verwendet wird.
  • Zukünftige Bereitschaft: Diese Änderung entspricht den sich entwickelnden PKI- / Browser-Vertrauensmodellen und hilft Unternehmen, sich für neuere Sicherheitsmodelle und Automatisierung zu positionieren.

Wer ist nicht betroffen?

Die meisten Websites, die Zertifikate nur für die Serverauthentifizierung verwenden (also typisches TLS / HTTPS), sind nicht betroffen. Wenn Sie das Zertifikat nur zum Schutz Ihrer Website für Benutzer verwenden, sind für diese Änderung keine Maßnahmen erforderlich.

Wer ist betroffen?

Diese Änderung betrifft Organisationen, die öffentlich vertrauenswürdige Serverzertifikate für die Clientauthentifizierung (auch gegenseitige TLS / mTLS genannt) oder die Server-zu-Server-Authentifizierung verwenden, die auf der clientAuth-EKU basieren. Beispielsweise können einige Finanzdienstleistungen, SaaS-Dienste oder mandantenfähige APIs von dieser Änderung betroffen sein.

Was Sie tun müssen

  • Wenn Sie außerhalb von GoDaddy gehostet werden : Stellen Sie sicher, dass beim Aktualisieren Ihres nächsten Zertifikats das vollständige Paket installiert wird, das von den Download-Endpunkten oder der Benutzeroberfläche bereitgestellt wird.
  • Wenn Sie in einem Anwendungsfall Zertifikate verwenden, die auf ClientAuth (mTLS) basieren : Stellen Sie sicher, dass Sie diese Workflows zur Verwendung eines selbstsignierten Zertifikats oder einer Lösung einer privaten Zertifizierungsstelle migrieren.

Teams sollten außerdem bestätigen, dass keine internen Features oder Dokumentationen davon ausgehen, dass DV-Leaf-Zertifikate ClientAuth EKU enthalten, da Leaf-Zertifikate, die von R1 ausgestellt wurden, dies nicht enthalten.

Heißt das, dass alle Zertifikate, die nach dem 15. Juni 2026 ausgestellt wurden, ungültig sind?

Nein. Zertifikate, die vor dem 15. Juni 2026 ausgestellt wurden und clientAuth enthalten, bleiben unter dem vorhandenen Vertrauensmodell gültig (bis zu ihrem Ablauf). Die Änderung betrifft nur neue öffentliche Zertifikate, die ab diesem Datum ausgestellt wurden.

Wenn ich mein Zertifikat nur für typisches Website-HTTPS (Serverauthentifizierung) verwende, muss ich dann etwas tun?

Befindet sich Ihr Hosting außerhalb von GoDaddy, müssen Sie dennoch sicherstellen, dass das Paket richtig verwendet wird.

Was genau ist in diesem Zusammenhang „Clientauthentifizierung“?

Clientauthentifizierung bezieht sich auf die Verwendung eines Zertifikats durch einen Client (Benutzer, Gerät oder einen anderen Server) zur Authentifizierung beim Server. Sie wird häufig bei der mTLS-Authentifizierung (gegenseitige TLS-Authentifizierung) oder der Server-zu-Server-API-Authentifizierung eingesetzt, bei der der Server das vom verbindenden Client bereitgestellte Zertifikat überprüfen muss.

Kann ich trotzdem clientAuth-Zertifikate verwenden?

Ja - & mdash; aber für das öffentliche Vertrauen müssen Sie ein Zertifikat verwenden, das speziell für die Clientauthentifizierung ausgestellt wurde (dh eine dedizierte clientAuth-EKU) oder eine private Zertifizierungsstelle für Ihre internen Systeme verwenden. Öffentliche Serverzertifikate mit der EKU clientAuth werden in Chrome nicht mehr als vertrauenswürdig eingestuft, wenn sie nach dem 15. Juni 2026 ausgestellt wurden.

Erzwingen andere Browser diese Änderung oder nur Chrome?

Die Richtlinie stammt aus dem Chrome Root-Programm, doch Änderungen im öffentlichen PKI-Ökosystem wirken sich häufig auf andere Browser und Truststores aus. Es ist ratsam, eine breitere Anwendbarkeit anzunehmen oder zumindest, dass künftige Compliance plattformübergreifend von Bedeutung sein wird.

Gilt dies für interne / private CA-Zertifikate?

Nein & & ndash; Die Änderung betrifft nur öffentlich vertrauenswürdige SSL / TLS-Zertifikate (diejenigen, denen die öffentlichen Root-Shops vertrauen). Die für die interne Clientauthentifizierung verwendete Infrastruktur privater Zertifizierungsstellen ist nicht direkt betroffen.

Wann müssen wir auf diese Änderung vorbereitet sein?

Der angestrebte Zeitplan ist der 27. Mai 2026. Bis zu diesem Datum sollten die zuständigen Teams die Bereitschaftsüberprüfung abgeschlossen haben (Ausgabekonfiguration, Richtigkeit von Paketen / Downloads, Anleitung zur Installation der Bereitstellungskette, Überwachung und EKU-Abhängigkeitsprüfungen), damit die Einführung ohne Serviceunterbrechung erfolgen kann.

Weitere Informationen