Authentifizierung mit öffentlichen Zertifikaten? Stoppen Sie damit. Was Sie bis 2026 ändern müssen
Bis Mai 2026 werden öffentliche Zertifizierungsstellen (CAs) aufgrund der neuen Root-Programmregeln von Chrome die TLS-Client-Authentifizierung nicht mehr unterstützen. Unternehmen, die für die Authentifizierung von Benutzern, Geräten oder Anwendungen auf öffentliche SSL/TLS-Zertifikate angewiesen sind, müssen auf private CAs umsteigen. Diese Umstellung betrifft VPNs, mTLS, Wi-Fi-Onboarding und mehr. Moderne private CA-Lösungen in Kombination mit Certificate Lifecycle Management (CLM) bieten einen sicheren und skalierbaren Weg in die Zukunft.
Im Mai 2026 wird es zu einer grundlegenden Umstellung in der Public-Key-Infrastruktur (PKI) kommen, die von den meisten Unternehmen nicht verfolgt wird, aber viele zu spüren bekommen werden. Aufgrund aktualisierter Anforderungen des Chrome Root Program und kürzlich veröffentlichter Ankündigungen von Zertifizierungsstellen (CAs) werden öffentliche CAs keine Zertifikate mehr ausstellen, die die TLS-Client-Authentifizierung unterstützen.
Für Unternehmen, die diese Zertifikate zur Authentifizierung von Benutzern, Geräten oder Anwendungen verwenden, bedeutet diese Änderung eine feste Frist. Bestehende Authentifizierungsworkflows, insbesondere solche, die stillschweigend auf kostenlose oder automatisierte öffentliche CAs setzen, werden fehlschlagen, sofern Unternehmen nicht auf private CAs umsteigen.
Diese Umstellung ist keine geringfügige Aktualisierung der Richtlinien. Es handelt sich um eine strukturelle Neuausrichtung, die die Art und Weise neu definiert, wie die Authentifizierung in der gesamten Unternehmensinfrastruktur gehandhabt werden muss. Und sie kommt viel früher, als den meisten bewusst ist.
Die Richtlinienänderung hinter all dem
Der Ursprung dieser Änderung liegt in der Chrome Root Program Policy 1.6, die vorschreibt, dass Zertifikatshierarchien, die im Vertrauensspeicher von Chrome enthalten sind, bis Juni 2026 ausschließlich für die TLS-Serverauthentifizierung verwendet werden dürfen. Kurz gesagt, öffentliche Zertifizierungsstellen dürfen keine Zertifikate mehr ausstellen, die sowohl die erweiterten Schlüsselverwendungszwecke (EKUs) „id-kp-serverAuth“ als auch „id-kp-clientAuth“ enthalten. Diese EKUs definieren, wofür ein Zertifikat verwendet werden darf, in diesem Fall entweder für die Server- oder die Client-Authentifizierung.
Die Durchsetzung ist bereits im Gange.
Sectigo hat angekündigt, dass ab dem 15. September 2025 die Client Authentication EKU nicht mehr standardmäßig in neu ausgestellten SSL/TLS-Zertifikaten enthalten sein wird. Und bis zum 15. Mai 2026 wird Sectigo die Client Authentication EKU dauerhaft aus allen neu ausgestellten SSL/TLS-Zertifikaten entfernen. Nach diesem Datum werden keine Ausnahmen mehr gewährt.
Diese Richtlinienänderung folgt einem allgemeinen Trend, dass Browser keine Verzögerungen bei der Sperrung tolerieren. Anstatt gemischt genutzte öffentliche Zertifikate weiterhin zu tolerieren, hat Chrome sich für Klarheit entschieden: Öffentliche PKI dient ausschließlich der Serverauthentifizierung. Wenn Sie eine Clientauthentifizierung benötigen, verwenden Sie eine private CA.
Was ist TLS-Client-Authentifizierung und warum sollten Sie sie verwenden?
Die TLS-Client-Authentifizierung ermöglicht es Systemen, die Identität von Clients, Benutzern, Geräten oder Anwendungen zu überprüfen, wenn diese versuchen, eine Verbindung zu einem Server herzustellen. Sie unterscheidet sich von der bekannteren TLS-Server-Authentifizierung (die in HTTPS verwendet wird), die Websites überprüft.
Einige häufige Anwendungsfälle sind:
- VPN-Zugang für die Ausstellung von Zertifikaten für Mitarbeiter-Laptops, um deren Identität bei der Fernverbindung zu überprüfen.
- Wi-Fi-Onboarding zur Authentifizierung von Mitarbeitergeräten und zur Sicherung von Netzwerken ohne Weitergabe statischer Passwörter.
- Salesforce-Anmeldung oder andere SSO-Workflows, die auf in Endpunktgeräten eingebetteten Client-Zertifikaten basieren.
- Mutual TLS (mTLS) für APIs, insbesondere in CICD-Pipelines oder zwischen Microservices in Zero-Trust-Architekturen.
- Geräte- oder Workload-Identität in DevOps-Umgebungen, einschließlich containerbasierter Dienste.
Das Hauptproblem ist, dass viele Unternehmen in diesen Workflows unwissentlich öffentliche Zertifizierungsstellen für die Client-Authentifizierung verwenden, oft weil dies einfach und kostengünstig ist oder weil sie in Automatisierungstools wie ACME enthalten sind.
Google Chrome hat die Entfernung der Client-Authentifizierung zu einer Voraussetzung für die Beibehaltung von Roots im Chrome Root Store gemacht. Da die meisten anderen Browser denselben Root-Programmen folgen, werden wirklich global vertrauenswürdige Client-Authentifizierungszertifikate verschwinden.
Sobald die großen öffentlich vertrauenswürdigen Zertifizierungsstellen die Client Authentication EKUs 2025/2026 aus ihren TLS-Produktlinien entfernt haben, wird es für Unternehmen, die weiterhin auf ein TLS-Client-Authentifizierungszertifikat zur Identifizierung von Clients angewiesen sind, schwierig (und bald unmöglich) sein, Ersatz zu finden. Alle großen öffentlichen Zertifizierungsstellen haben inzwischen einen Zeitplan für die Abschaffung veröffentlicht.
Moderne private Zertifizierungsstellen: Nicht mehr so aufwendig wie früher
Die Client-Authentifizierung ist im Grunde eine interne Sicherheitsfunktion. Sie erfordert Flexibilität, detaillierte Kontrolle und die Gewissheit, dass Zertifikate nicht durch externe Richtlinienänderungen widerrufen werden. Öffentliche Zertifizierungsstellen wurden nie für diesen Zweck konzipiert.
Bis vor kurzem haben viele Unternehmen sie dennoch verwendet, oft ohne sich der Auswirkungen bewusst zu sein. Öffentliche Zertifikate waren leicht zu beschaffen, automatisierungsfreundlich und erforderten keine interne PKI-Infrastruktur. Aber sie hatten auch Einschränkungen:
- Feste Zertifikatsprofile, die nicht an interne Anwendungsfälle angepasst werden können.
- Öffentliche Audits und Compliance-Vorgaben des CA/Browser Forum.
- Keine Kontrolle über Ausstellungsfenster, Sperrkriterien oder Lebenszyklusrichtlinien.
- Gefahr durch Änderungen der Browser- und Plattformrichtlinien, wie sie derzeit stattfinden.
Im Gegensatz dazu geben private Zertifizierungsstellen Unternehmen die vollständige Kontrolle über die Ausstellung, das Profildesign, die Sperrung, die Erneuerung und die Automatisierung. Noch wichtiger ist, dass sie keinen externen Root-Programm-Einschränkungen unterliegen. Und moderne private CA-Lösungen sind heute viel einfacher zu implementieren als früher.
In der Vergangenheit hatten private Zertifizierungsstellen den Ruf, teuer, schwer zu verwalten und langsam zu implementieren zu sein. Unternehmen mussten ihre PKI-Infrastruktur von Grund auf neu aufbauen und waren dabei oft auf veraltete Tools und manuelle Prozesse angewiesen.
Das ist heute nicht mehr der Fall.
Moderne private Zertifizierungsstellen, insbesondere cloudnative wie Sectigo, können innerhalb von Minuten bereitgestellt werden, lassen sich automatisch skalieren und unterstützen Protokolle wie ACME, EST und SCEP für eine nahtlose Zertifikatsregistrierung. Sie bieten:
- Anpassbare Zertifikatsprofile für eine Vielzahl interner Anwendungsfälle.
- Private Zertifizierungsstellen für einzelne Anwendungsfälle, wenn eine Trennung der Aufgabenbereiche gewünscht ist.
- Vollständige API-Unterstützung für die Integration in DevOps-, MDM- und Sicherheitsplattformen.
- Automatisierung des Lebenszyklus und Durchsetzung von Richtlinien durch CLM-Plattformen (Certificate Lifecycle Management).
Diese Entwicklung ist so bedeutend, dass sie selbst zur Änderung der Chrome-Richtlinie beigetragen hat. Jason Soroko, Senior Fellow bei Sectigo, merkt dazu an:
„Google fühlt sich dazu in der Lage, weil sie wissen, dass wir endlich über leichtgewichtige, schlüsselfertige private CA-Optionen verfügen. Vor 15 Jahren hätten sie diesen Schritt nicht wagen können.“
Mit anderen Worten: Die private CA-Infrastruktur hat endlich das Problem gelöst, für das sie eigentlich gedacht war.
Wie CLM das Bild vervollständigt
Bei der Umstellung auf eine private CA geht es nicht nur darum, Zertifikate zu ersetzen, sondern auch darum, die Kontrolle über die Verwaltung dieser Zertifikate zu übernehmen.
Angesichts einer Lebensdauer von SSL/TLS-Zertifikaten von nur noch 47 Tagen ist es nicht mehr praktikabel, Zertifikate mit Tabellenkalkulationen zu verfolgen oder darauf zu hoffen, dass Erneuerungsskripte weiterhin funktionieren. Transparenz, Automatisierung und Durchsetzung von Richtlinien müssen von Anfang an integriert sein.
Hier kommt das Zertifikatslebenszyklusmanagement (CLM) ins Spiel. Eine robuste CLM-Plattform hilft Ihnen dabei
- Entdecken Sie jedes Zertifikat in Ihrer Umgebung, egal ob öffentlich oder privat.
- Klassifizieren und kennzeichnen Sie Zertifikate nach Anwendungsfall, System und Ablaufdatum.
- Automatisieren Sie die Ausstellung, Erneuerung und Sperrung in großem Umfang.
- Setzen Sie Richtlinien für Schlüssellänge, EKU, Profilvorlagen und mehr durch.
- Vermeiden Sie Ausfälle aufgrund abgelaufener oder falsch konfigurierter Zertifikate.
- Alle Zertifikate auf einen Blick in einer einheitlichen Ansicht, egal ob privat oder öffentlich.
Egal, wie gut Ihre Zertifizierungsstelle ist, ohne CLM werden Sie Schwierigkeiten haben, angesichts der sich schnell verändernden digitalen Landschaft agil zu bleiben.
„Alle Wege führen zu CLM“, wie Jason es ausdrückte. „Jedes Zertifikat hätte von Anfang an verwaltet werden müssen.“
Was Sie als Nächstes tun sollten
1. Erfassen Sie Ihre interne PKI
Beginnen Sie damit, zu ermitteln, wo in Ihrem Unternehmen die TLS-Client-Authentifizierung verwendet wird:
- Welche Geräte, Anwendungen oder Dienste authentifizieren sich mit Zertifikaten?
- Welche Zertifizierungsstellen haben diese ausgestellt?
- Werden einige dieser Zertifikate über öffentliche ACME-Workflows (z. B. Let's Encrypt) ausgestellt?
Wenn Sie sich nicht sicher sind, kann Ihnen Sectigo Certificate Manager dabei helfen, interne Zertifikate in Cloud-, lokalen und hybriden Umgebungen zu ermitteln und zu inventarisieren.
2. Bewerten Sie Risiken und Zeitplan
Wie bereits erwähnt, müssen alle öffentlichen Zertifizierungsstellen die Unterstützung für die TLS-Client-Authentifizierung bis Mai 2026 vollständig einstellen. Alle Zertifikate, die die Client-Authentifizierung unterstützen und von diesen Quellen ausgestellt wurden, müssen durch Zertifikate ersetzt werden, die von einer privaten Zertifizierungsstelle ausgestellt wurden.
3. Stellen Sie eine moderne private Zertifizierungsstelle bereit
Mit der cloudbasierten privaten Zertifizierungsstellenlösung von Sectigo können Sie Zertifikate für folgende Zwecke ausstellen und verwalten:
- VPN- und WLAN-Authentifizierung
- Geräte- und Workload-Identität
- mTLS- und API-Authentifizierung
- Entwicklerumgebungen und CI/CD-Pipelines
Sie ist für eine schnelle Bereitstellung konzipiert und lässt sich über verschiedene Umgebungen hinweg skalieren. Dank der Unterstützung von ACME, EST und SCEP sowie der sofort einsatzbereiten Integration in Microsoft ADCS und Cloud-Identitätsplattformen können Sie private PKI ohne Infrastrukturprobleme online bringen.
4. Automatisierung mit Zertifikatslebenszyklusmanagement
Sobald Ihre private Zertifizierungsstelle betriebsbereit ist, müssen Sie als Nächstes für vollständige Transparenz und Automatisierung sorgen. Der Sectigo Certificate Manager bietet Ihnen:
- Vollständige Bestandsaufnahme aller Zertifikate (öffentlich und privat)
- Rollenbasierte Ausstellungsrichtlinien
- Automatische Verlängerung und Rotation
- Ablaufbenachrichtigungen und Audit-Protokollierung
Private PKI ist nicht mehr optional
Die Abschaffung der TLS-Client-Authentifizierung durch öffentliche Zertifizierungsstellen ist nicht nur eine Aktualisierung der Richtlinien, sondern eine strukturelle Änderung der Art und Weise, wie die Authentifizierung gehandhabt werden sollte. Damit wird eine Krücke entfernt, auf die sich viele Unternehmen jahrelang unwissentlich gestützt haben.
Die gute Nachricht: Private Zertifizierungsstellen sind nicht mehr das Hindernis, das sie einmal waren. Und da die Tools für die Zertifikatsverwaltung aufholen, gab es noch nie einen besseren Zeitpunkt, um die Kontrolle zurückzugewinnen.
Wenn Sie immer noch WLAN-Passwörter weitergeben oder Client-Zertifikate von öffentlichen Zertifizierungsstellen zur Authentifizierung von Laptops verwenden, ist es Zeit zu handeln. Die erforderliche Infrastruktur ist verfügbar und die Frist läuft.
Sectigo bietet die Lösung, die Ihr Unternehmen benötigt, um konform und agil zu bleiben. Mit einer schlüsselfertigen, erstklassigen privaten Zertifizierungsstelle, die CA-unabhängig ist, und einer sicheren, einfachen und skalierbaren Plattform können Sie Ihre öffentlichen und privaten Zertifikate zu einem einzigen zusammenführen.
