Ende von clientAuth: Warum mTLS mit öffentlichen Zertifikaten ausläuft

Ein öffentlich vertrautes TLS-Zertifikat konnte lange zwei Dinge zugleich: einen Server gegenüber Browsern ausweisen und einen Client gegenüber einem anderen Server. Möglich machte das die Erweiterung Extended Key Usage mit den Zwecken serverAuth und clientAuth. Diese Doppelrolle endet. Die Richtlinie des Chrome Root Program verlangt Hierarchien, die ausschließlich der Server-Authentifizierung dienen.

Die Stichtage

Nach der Chrome Root Program Policy in der Fassung 1.8 gelten zwei Daten:

Seit dem 15. Juni 2026 dürfen neu an die CCADB gemeldete Zwischenzertifizierungsstellen nur noch den Zweck serverAuth ausweisen.
Ab dem 15. März 2027 gilt dasselbe für jedes ausgestellte Endzertifikat.

Die Zertifizierungsstellen stellen früher um. DigiCert etwa stellt öffentliche TLS-Zertifikate seit dem 1. Oktober 2025 standardmäßig ohne clientAuth aus und entfernt die Option nach eigener Ankündigung zum 1. März 2027 vollständig. Wer sich auf den Chrome-Stichtag verlässt, erfährt die Änderung deshalb womöglich schon bei der nächsten Verlängerung.

Bestehende Zertifikate bleiben bis zu ihrem Ablauf gültig. Weil die maximale Laufzeit seit dem 15. März 2026 bei 200 Tagen liegt, ist der Übergang aber kurz: Ein Zertifikat, das am letzten zulässigen Tag noch mit clientAuth ausgestellt wird, läuft spätestens Ende September 2027 aus. Danach trägt kein gültiges Endzertifikat aus einer von Chrome vertrauten Hierarchie mehr diesen Zweck.

Wo es bricht

Browser sind von der Änderung kaum betroffen, denn sie prüfen Server. Betroffen sind Verbindungen, bei denen ein System sich mit einem öffentlichen Zertifikat als Client ausweist:

Partnerschnittstellen: B2B-Verbindungen, bei denen beide Seiten sich per mTLS authentisieren und das Client-Zertifikat von einer öffentlichen CA stammt.
Server-zu-Server-Verkehr: Dienste, die ihr eigenes Serverzertifikat zugleich als Client-Identität gegenüber anderen Diensten verwenden.
Geräte und Agenten: Endpunkte, die mit öffentlich ausgestellten Zertifikaten gegenüber einem zentralen Dienst auftreten.

Das Tückische ist der Zeitpunkt. Der Fehler zeigt sich nicht am Stichtag, sondern bei der ersten Verlängerung danach, oft automatisiert und oft nachts. Das neue Zertifikat ist gültig, der TLS-Handshake scheitert trotzdem, weil die Gegenseite den Zweck clientAuth verlangt.

Client-Identitäten gehören in eine eigene PKI

Chrome schafft mTLS nicht ab. Die Richtlinie trennt nur die Zwecke: Öffentliche CAs weisen Server gegenüber der Allgemeinheit aus, Client-Identitäten werden in einer Vertrauensbeziehung ausgestellt, die die beteiligten Parteien selbst kontrollieren. Das ist sicherheitlich ohnehin sauberer. Wer einer öffentlichen CA als Client-Aussteller vertraut, akzeptiert potenziell jedes Zertifikat dieser CA, nicht nur die des eigenen Partners.

Für den Umstieg haben sich vier Schritte bewährt. Erstens das Inventar: Welche Zertifikate tragen heute clientAuth, und welche davon werden tatsächlich als Client eingesetzt? Das zeigt sich nicht am Zertifikat allein, sondern erst im Abgleich mit den Verbindungen. Zweitens eine eigene Zertifizierungsstelle für Client-Zwecke, getrennt von allem, was Server ausweist. Drittens die Abstimmung mit Partnern, denn jede Gegenseite muss den neuen Vertrauensanker hinterlegen, und das braucht Vorlauf. Viertens die Automatisierung der Ausstellung und Erneuerung, damit die eigene PKI nicht zur neuen manuellen Last wird.

NextPKI folgt genau diesem Muster: erst den Bestand sichtbar machen, dann die Erneuerung automatisieren, unabhängig von der ausstellenden CA. Der entscheidende Schritt liegt aber vor jedem Werkzeug, nämlich die Verbindungen zu finden, die heute stillschweigend auf clientAuth angewiesen sind.

Der 15. März 2027 ist nicht das Datum, an dem mTLS bricht. Er ist das Datum, ab dem jede Verlängerung es brechen kann.