TLS-Zertifikate: Ende der Doppelverwendung ab 2026
Update: Chrome verschiebt Frist auf März 2027
Seit Veröffentlichung der ursprünglichen Meldung haben sich die Fristen erneut geändert. Die Google Chrome Root Program Policy v1.8 verschiebt die ursprünglich für Mitte Juni 2026 erwartete Anforderung auf den 15. März 2027. Ab diesem Datum dürfen neu ausgestellte öffentliche TLS-Serverzertifikate nur noch für Server-Authentifizierung verwendet werden. Der Verwendungszweck Client Authentication darf dann nicht mehr in der Extended Key Usage enthalten sein.
Die Umsetzung kann je nach Zertifizierungsstelle früher erfolgen. SwissSign plant, die neuen Anforderungen voraussichtlich bis Ende Januar 2027 umzusetzen. Zertifikate, die bis dahin ausgestellt wurden, behalten ihre Gültigkeit bis zum jeweiligen Ablaufdatum. Let’s Encrypt folgt einem eigenen Zeitplan und stellt das entsprechende tlsclient-Profil bereits am 8. Juli 2026 ein.
Für Unternehmen reduziert sich damit in vielen Fällen der unmittelbare Zeitdruck. Der Handlungsbedarf bleibt jedoch bestehen: Wer öffentliche TLS/SSL-Zertifikate auch für Client-Authentifizierung nutzt, sollte die zusätzliche Zeit für Inventarisierung, Bewertung und Umstellung nutzen.
Öffentlich vertrauenswürdige TLS/SSL-Zertifikate dürfen künftig nicht mehr gleichzeitig für Server- und Client-Authentifizierung verwendet werden. Hintergrund sind neue Anforderungen der Root-Programme Browserhersteller. Unternehmen, die entsprechende Zertifikate einsetzen, sollten ihre Infrastruktur rechtzeitig überprüfen.
Was sich ändert
Bisher konnten viele öffentlich ausgestellte TLS-Zertifikate sowohl für die Server-Authentifizierung (z. B. HTTPS) als auch für die Client-Authentifizierung (z. B. Mutual TLS) genutzt werden. Möglich war dies über die sogenannte Extended Key Usage (EKU), indem ein Zertifikat gleichzeitig die Einträge „Server Authentication“ und „Client Authentication“ enthielt.
Diese Doppelverwendung wird nun abgeschafft. Öffentlich vertrauenswürdige TLS-Zertifikate dürfen künftig nur noch für Server-Authentifizierung eingesetzt werden. Für die Client-Authentifizierung sind künftig separate Zertifikate erforderlich, etwa aus einer privaten PKI.
Zeitplan der Umstellung
Die Umsetzung erfolgt je nach Zertifizierungsstelle zu unterschiedlichen Zeitpunkten. Während einige Anbieter bereits 2026 umstellen, sieht die Chrome Root Program Policy v1.8 die Anforderung ab dem 15. März 2027 vor.
Wer ist betroffen?
Betroffen sind insbesondere Umgebungen, in denen öffentliche TLS-Zertifikate zusätzlich zur Client-Authentifizierung verwendet werden, etwa:
- Mutual TLS (mTLS) zwischen Systemen
- API-Authentifizierung über Client-Zertifikate
- Geräte- oder Maschinen-Authentifizierung
- interne Dienste mit kombinierter Zertifikatsverwendung
Der klassische Einsatz von TLS-Zertifikaten für HTTPS-Webserver ist nicht betroffen.
Empfohlene Vorkehrungen
Organisationen sollten prüfen, ob entsprechende Zertifikate im Einsatz sind, und ihre Konfigurationen gegebenenfalls anpassen:
- Zertifikatsinventar erstellen
- Zertifikate mit kombinierter EKU identifizieren
- Client-Authentifizierungs-Szenarien prüfen
- separate Client-Zertifikate einführen (setzen Sie sich hier mit Ihrem TrustCenter in Verbindung, welche Alternativen angeboten werden oder verwenden Sie hierfür eine eigene private trust Variante)
- automatisierte Zertifikatsprozesse anpassen
Für die Umsetzung kann ein zentraler Überblick über vorhandene Zertifikate hilfreich sein. Mit essendi cd lässt sich ein Zertifikatsinventar aufbauen und gezielt nach Zertifikaten mit kombinierter Extended Key Usage suchen. Die folgende Anpassung und Erneuerung der Zertifikate kann über automatisierte Prozesse erfolgen, beispielsweise mit essendi xc, das den gesamten Zertifikatslebenszyklus abdeckt und Änderungen kontrolliert ausrollt.