mTLS 2026: Warum klassische Client-Zertifikate ausgedient haben

Digitale Zertifikate übernehmen unterschiedliche Aufgaben: Sie authentifizieren Server, Clients, Geräte oder Maschinen und schaffen damit Vertrauen in digitale Verbindungen. Lange Zeit konnten bestimmte öffentlich vertrauenswürdige TLS-Zertifikate neben der Serverauthentifizierung auch für weitere Zwecke eingesetzt werden.

Diese Zeit geht zu Ende. Die Zertifikatswelt entwickelt sich in Richtung klar getrennter Verwendungszwecke. Gleichzeitig gewinnt mTLS in Zero-Trust-, API-, Cloud-, Microservices- und IoT-Szenarien weiter an Bedeutung.

In unserem Beitrag „mTLS verstehen: So funktioniert mutual TLS – Grundlagen, Vorteile & Unterschiede zu klassischem TLS“ haben wir bereits ausführlich erklärt, wie Mutual TLS funktioniert. In diesem Folgebeitrag gehen wir einen Schritt weiter: Was verändert sich bei Client-Zertifikaten und wie sollten Unternehmen ihre Zertifikatsarchitektur künftig aufbauen?

Was sind Client-Zertifikate?

Ein Client-Zertifikat ist ein digitales Zertifikat, mit dem ein Client seine Identität gegenüber einem Server kryptografisch nachweisen kann. „Client“ bedeutet dabei keineswegs zwangsläufig einen Menschen beziehungsweise dessen Computer.

Ein Client kann beispielsweise sein:

• ein Benutzergerät
• ein Server
• eine Anwendung
• ein API-Client
• ein IoT-Gerät
• eine Maschine oder ein Workload

Das unterscheidet Client-Zertifikate von den Zertifikaten, die wir aus dem klassischen HTTPS-Kontext kennen. Bei einer normalen TLS-Verbindung weist zunächst der Server seine Identität nach. Der Browser beziehungsweise ein anderer Client prüft dessen Zertifikat und kann feststellen, ob er tatsächlich mit dem vorgesehenen Server kommuniziert.

Vereinfacht dargestellt:

Klassisches TLS:

Client → prüft → Server-Zertifikat

Bei mTLS kommt eine zweite Authentifizierung hinzu:

Client ↔ beide Seiten prüfen Zertifikate ↔ Server

Beide Kommunikationspartner besitzen dafür ein Zertifikat und das zugehörige Schlüsselpaar. Der Server überprüft zusätzlich das vom Client vorgelegte Zertifikat, bevor er den Zugriff gewährt. Wie sich diese Identitäten von klassischen Benutzerkonten unterscheiden, erklären wir im Beitrag „Maschinenidentitäten einfach erklärt“.

Warum klassische Client-Zertifikate 2026 neu bewertet werden müssen

Öffentlich vertrauenswürdige TLS-Zertifikate waren in der Vergangenheit häufig mit mehreren Extended Key Usages ausgestattet. Ein Zertifikat konnte dadurch beispielsweise sowohl für die Serverauthentifizierung (serverAuth) als auch für die Client-Authentifizierung (clientAuth) vorgesehen sein.

Diese Mehrzwecknutzung passt nicht mehr zu der Richtung, in die sich die öffentlich vertrauenswürdige PKI entwickelt. Mit dem Ballot SC-081v3 hat das CA/Browser Forum im April 2025 einstimmig beschlossen, die clientAuth-EKU aus öffentlich vertrauenswürdigen TLS-Zertifikaten zu entfernen. Getragen wurde der Beschluss von Google, Apple, Microsoft und Mozilla sowie 25 stimmberechtigten Zertifizierungsstellen.

Die Umsetzung erfolgt in zwei Stufen. Zahlreiche Zertifizierungsstellen haben sie bereits vorweggenommen.

Bereits erfolgt

• 01.10.2025 – DigiCert stellt clientAuth nicht mehr standardmäßig aus.
• 14.10.2025 – Sectigo zieht nach.
• 11.02.2026 – Let’s Encrypt entfernt clientAuth aus dem Standardprofil.
• 15.03.2026 – Die maximale Laufzeit öffentlicher TLS-Zertifikate sinkt auf 200 Tage.
• 15.06.2026 – Erste Stufe der Trennung: Neu veröffentlichte Zwischenzertifizierungsstellen dürfen nicht mehr beide Verwendungszwecke tragen.
• 08.07.2026 – Let’s Encrypt schaltet das gesonderte Client-Profil ab.

Noch offen

• 10.02.2027 – Sectigo: harte Frist für die Umstellung.
• 01.03.2027 – DigiCert entfernt clientAuth vollständig.
• 15.03.2027 – Zweite Stufe und Endpunkt: Neu ausgestellte öffentlich vertrauenswürdige Endzertifikate enthalten ausschließlich serverAuth. Eine Verlängerung ist nicht vorgesehen.

Sechs der neun Termine sind damit bereits verstrichen. Wer heute noch ein Mehrzweckzertifikat im Einsatz hat, arbeitet also nicht mit einer kommenden, sondern mit einer auslaufenden Konstruktion.

Dabei geht es ausdrücklich nicht darum, Client-Zertifikate abzuschaffen. Client-Authentifizierungszertifikate sollen lediglich nicht mehr aus denselben öffentlichen Hierarchien stammen, denen Browser für die Serverauthentifizierung vertrauen. Welche Fristen im Einzelnen gelten und wer betroffen ist, haben wir im Beitrag „Client-Authentifizierungs-EKU: Was sich ändert“ zusammengestellt.

Vom Mehrzweckzertifikat zum klar definierten Einsatzzweck

Die Entwicklung lässt sich auf eine einfache Formel bringen. Statt eines Zertifikats, das möglichst viele Aufgaben gleichzeitig erfüllt, geht der Trend zu spezialisierten Zertifikatsprofilen:

Bisher teilweise:

Ein öffentliches Zertifikat → Serverauthentifizierung + Client-Authentifizierung + weitere Zwecke

Zunehmend:

Server-Zertifikat → Serverauthentifizierung
Client- beziehungsweise Gerätezertifikat → Client-Authentifizierung
Weitere Zertifikatstypen → jeweils definierter Einsatzzweck

Diese Trennung hat einen wesentlichen Vorteil: Zertifikate lassen sich entsprechend ihres tatsächlichen Einsatzzwecks ausstellen, absichern, verwalten und mit passenden Richtlinien versehen.

Für Unternehmen bedeutet das: Ein öffentlich vertrauenswürdiges TLS-Serverzertifikat sollte nicht automatisch als universelle digitale Identität für Server, Clients und Geräte betrachtet werden.

Client-Zertifikate und mTLS: So funktioniert die gegenseitige Authentifizierung

Die technische Funktionsweise von mTLS haben wir in unserem Grundlagenbeitrag bereits ausführlich erläutert. Deshalb an dieser Stelle nur die wichtigsten Punkte.

Bei klassischem TLS besitzt der Server ein Zertifikat. Der Client überprüft dieses Zertifikat und stellt anschließend eine verschlüsselte Verbindung her.

Bei mTLS kommt die Authentifizierung des Clients hinzu. Der Client besitzt ein eigenes Zertifikat und den dazugehörigen privaten Schlüssel. Während des Verbindungsaufbaus fordert der Server das Client-Zertifikat an und überprüft unter anderem dessen Vertrauenskette und Gültigkeit. Der Client muss zugleich kryptografisch nachweisen, dass er den zugehörigen privaten Schlüssel besitzt.

Nur wenn die Prüfung erfolgreich verläuft, wird der Client als vertrauenswürdig authentifiziert und die Verbindung entsprechend fortgesetzt.

Cloudflare bringt den Unterschied auf den Punkt: Während Standard-TLS die Identität des Servers gegenüber dem Client prüft, ergänzt mTLS eine zweite Prüfung, bei der der Server die Identität des Clients anhand seines Client-Zertifikats verifiziert. Damit entsteht eine gegenseitig authentifizierte Verbindung.

Warum mTLS 2026 immer wichtiger wird

Während die Mehrzwecknutzung öffentlich vertrauenswürdiger Zertifikate zurückgedrängt wird, steigt der Bedarf an dedizierten Client-Zertifikaten für mTLS. Verantwortlich dafür ist vor allem die Art und Weise, wie moderne IT-Infrastrukturen aufgebaut sind.

Immer mehr Kommunikation findet nicht mehr zwischen einem Menschen und einer Website statt. Anwendungen kommunizieren mit APIs, Microservices tauschen untereinander Daten aus, IoT-Geräte greifen auf Cloud-Plattformen zu und Workloads werden dynamisch gestartet und wieder beendet. In vier Bereichen ist die Entwicklung besonders deutlich.

Zero Trust

Zero Trust geht davon aus, dass keiner Verbindung automatisch vertraut werden sollte, auch nicht innerhalb des eigenen Netzwerks. Jede Identität muss zuverlässig überprüft werden, bevor ein Zugriff gewährt wird.

mTLS liefert dafür genau den Mechanismus, den Zero Trust benötigt: eine kryptografische Authentifizierung, die sich nicht durch gestohlene Zugangsdaten umgehen lässt. Ein Client ohne gültiges Zertifikat kommt gar nicht erst zum Verbindungsaufbau. Was hinter dem Konzept steht, erklären wir im Beitrag „Zero Trust: kein blindes Vertrauen“.

APIs

APIs verbinden immer mehr Anwendungen und Dienste miteinander, häufig über Unternehmensgrenzen hinweg. Klassische Zugangsdaten oder Tokens sichern dabei zwar den Zugriff ab, sie lassen sich aber kopieren und weitergeben.

mTLS ergänzt eine zweite Ebene: Nur ein Client, der ein gültiges Zertifikat und den passenden privaten Schlüssel besitzt, darf Anfragen stellen. Cloudflare setzt mTLS aus genau diesem Grund zur Authentifizierung von API-Endpunkten ein. Für Unternehmen mit vielen angebundenen Partnern entsteht damit eine Zugriffskontrolle, die sich zentral widerrufen lässt.

Microservices

Moderne Anwendungen bestehen häufig aus Dutzenden oder Hunderten miteinander kommunizierenden Diensten. Jeder dieser Dienste muss wissen, mit welchem anderen Dienst er gerade spricht.

mTLS ermöglicht eine verschlüsselte und gegenseitig authentifizierte Kommunikation zwischen den Services. In Service-Mesh-Architekturen ist das inzwischen der Standardweg, um Vertrauen innerhalb der Anwendung herzustellen, ohne jeden Dienst einzeln mit Zugangsdaten auszustatten.

IoT und Maschinenidentitäten

IoT-Geräte besitzen in aller Regel keinen klassischen Benutzer-Login. Es gibt niemanden, der ein Passwort eingibt oder einen zweiten Faktor bestätigt. Trotzdem müssen sich diese Geräte gegenüber Plattformen, Gateways oder anderen Geräten ausweisen.

Client- beziehungsweise Gerätezertifikate eignen sich dafür besonders gut: Sie hängen am Gerät, nicht an einer Person, und lassen sich gezielt ausstellen und widerrufen. Cloudflare nennt IoT-Geräte ausdrücklich als Beispiel für Clients, die sich per mTLS authentifizieren können, obwohl kein Identity Provider vorhanden ist.

Genau hier entsteht für viele Unternehmen der größte Handlungsbedarf, denn die Zahl der Geräte wächst schneller als die Prozesse, die sie verwalten. Wie Zertifikate im IoT-Umfeld eingesetzt werden, beschreiben wir in den Beiträgen „IoT-Sicherheit einfach erklärt: die Rolle von Zertifikaten und PKI“ und „IoT-Gerätezertifikate als Baustein für sichere Vernetzung“.

Dedizierte Client-Zertifikate statt Mehrzweck-TLS-Zertifikate

Damit kommen wir zur entscheidenden Botschaft: Die Zukunft von mTLS ist keineswegs mTLS ohne Client-Zertifikate. Ganz im Gegenteil.

Was zunehmend ausgedient hat, ist die Vorstellung, ein öffentlich vertrauenswürdiges TLS-Zertifikat könne als universelles Zertifikat für möglichst viele Authentifizierungszwecke dienen.

Für mTLS sollten Unternehmen stattdessen eine bewusst geplante Vertrauensarchitektur für Client-, Geräte- und Maschinenidentitäten aufbauen. Dazu gehören:

• dedizierte Client- beziehungsweise Gerätezertifikate
• eine eigene PKI beziehungsweise geeignete CA-Strukturen
• klar definierte Zertifikatsrichtlinien
• eine kontrollierte Ausstellung
• definierte Laufzeiten, die zum Einsatzzweck passen
• ein sicherer und schneller Widerruf

Der Punkt der Laufzeiten verdient dabei besondere Aufmerksamkeit. Seit dem 15. März 2026 sinkt die maximale Gültigkeit öffentlich vertrauenswürdiger TLS-Zertifikate schrittweise ab. Für eigene Client-Zertifikate lassen sich die Laufzeiten dagegen frei am Schutzbedarf ausrichten. Was die Verkürzung im Einzelnen bedeutet, lesen Sie im Beitrag „SSL-Zertifikate: Laufzeiten im Wandel“.

Ein Server, der öffentlich per HTTPS erreichbar ist, benötigt ein Zertifikat für die Serverauthentifizierung. Ein Gerät, das sich gegenüber diesem oder einem anderen Dienst ausweisen muss, erhält dagegen eine eigene Client- beziehungsweise Geräteidentität.

Eigene PKI für Client- und Maschinenidentitäten

Eine solche Architektur bedeutet nicht zwangsläufig, dass jedes Client-Zertifikat aus einer weltweit öffentlich vertrauenswürdigen PKI stammen muss.

Gerade für interne Geräte, Workloads, APIs oder Microservices kann eine private PKI sinnvoll sein. Dabei kontrolliert das Unternehmen selbst, welchen Zertifizierungsstellen die beteiligten Systeme vertrauen. Genau diesen Weg empfehlen die Root-Programme ausdrücklich für Anwendungsfälle der Client-Authentifizierung.

Entscheidend ist deshalb nicht „öffentlich oder privat“ als pauschale Antwort, sondern der konkrete Vertrauensbedarf: Wer muss dem Zertifikat vertrauen, wie wird die Identität geprüft und wie wird der gesamte Lebenszyklus kontrolliert? Wenn Systeme mehrerer Organisationen beteiligt sind, reicht eine rein interne PKI nicht aus, weil die Gegenstelle Ihren Root nicht aufnehmen wird. Für solche Fälle braucht es einen Vertrauensanker, den beide Seiten akzeptieren.

Client-Zertifikate 2026: Was Unternehmen jetzt tun sollten

Der Wandel hin zu klar getrennten Zertifikatszwecken ist ein guter Anlass, die eigene PKI- und Zertifikatslandschaft zu überprüfen. Unternehmen sollten dabei nicht nur nach ablaufenden Zertifikaten suchen, sondern vor allem untersuchen, wofür die vorhandenen Zertifikate tatsächlich verwendet werden.

1. Bestehende Client-Zertifikate inventarisieren

Am Anfang steht eine vollständige Bestandsaufnahme. Unternehmen sollten feststellen, wo Client-Zertifikate vorhanden sind, welche Systeme sie einsetzen, von welcher CA sie stammen und welchen Verwendungszweck sie erfüllen.

Besonders in historisch gewachsenen IT-Umgebungen können Zertifikate an Stellen eingesetzt werden, die im zentralen Zertifikatsmanagement längst nicht mehr bekannt sind. Welche Werkzeuge dabei helfen, zeigt unser Vergleich der Zertifikatsverwaltung.

2. Verwendungszwecke und EKUs prüfen

Im zweiten Schritt sollte geprüft werden, ob Zertifikate mehrere Aufgaben gleichzeitig erfüllen. Besonders relevant ist die Frage: Wird ein öffentlich vertrauenswürdiges TLS-Serverzertifikat gleichzeitig für die Client-Authentifizierung verwendet?

Dabei lohnt sich ein Blick auf die Extended Key Usages. Tauchen serverAuth und clientAuth gemeinsam auf, sollte geprüft werden, warum beide Einsatzzwecke benötigt werden und ob die Architektur angesichts der Fristen vom 15. Juni 2026 und 15. März 2027 weiterhin tragfähig ist.

3. Server- und Client-Authentifizierung sauber trennen

Anschließend sollte eine klare Zertifikatsarchitektur geschaffen werden. Vereinfacht gilt:

Server → Server-Zertifikat
Client oder Gerät → dediziertes Client- beziehungsweise Gerätezertifikat

Dadurch lassen sich unterschiedliche Sicherheitsanforderungen, Laufzeiten, Richtlinien und Vertrauensanker sauber trennen. Für die Serverseite finden Sie das passende Angebot in unserer Übersicht der SSL-Zertifikate.

4. Ein PKI-Konzept für Maschinenidentitäten aufbauen

Bei wenigen Client-Zertifikaten lassen sich viele Prozesse noch manuell beherrschen. Bei Hunderten, Tausenden oder sogar Zehntausenden Geräten und Workloads funktioniert das kaum noch zuverlässig.

Deshalb müssen Unternehmen frühzeitig klären: Welche CA stellt Client-Zertifikate aus? Wie wird ein neues Gerät registriert? Wie gelangt das Zertifikat sicher auf das Gerät? Wo wird der private Schlüssel gespeichert? Welchen CAs vertrauen Server und Gateways? Und was geschieht, wenn ein Gerät kompromittiert wird?

Damit wird mTLS von einer reinen Protokollfrage zu einer PKI- und Lifecycle-Aufgabe. Wer die Infrastruktur nicht selbst betreiben möchte, findet in unserer Managed PKI einen Weg, eigene Zertifikate auszustellen, ohne eine eigene Zertifizierungsstelle aufzubauen.

5. Den Zertifikats-Lifecycle automatisieren

Gerade dieser letzte Punkt wird künftig entscheidend. Denn die zunehmende Zahl digitaler Maschinenidentitäten führt zwangsläufig zu einer steigenden Anzahl von Zertifikaten.

Ausstellung, Bereitstellung, Überwachung, Erneuerung und Widerruf sollten deshalb möglichst automatisiert erfolgen. Ein Certificate Lifecycle Management macht Zertifikatsbestände zentral sichtbar und automatisiert wiederkehrende Prozesse. Die Grundlagen dazu erklären wir im Beitrag „Grundlagen des Zertifikatsmanagements“.

Für die technische Umsetzung hat sich das ACME-Protokoll etabliert, das Zertifikate vollautomatisch beantragt, ausstellt und erneuert. Wie es funktioniert, lesen Sie im Beitrag „Das ACME-Protokoll einfach erklärt“; das passende Werkzeug finden Sie unter ACME-Client.

Häufige Fragen zu Client-Zertifikaten und mTLS

Sind meine bestehenden Client-Zertifikate weiterhin gültig?

Ja. Die Änderungen betreffen ausschließlich neu ausgestellte Zertifikate. Bereits ausgestellte Zertifikate bleiben bis zu ihrem Ablaufdatum gültig. Entscheidend ist deshalb der Zeitpunkt der nächsten Erneuerung: Ab dem 15. März 2027 enthält ein neu ausgestelltes öffentlich vertrauenswürdiges Zertifikat kein clientAuth mehr.

Ist meine Website von der Änderung betroffen?

Nein, sofern Sie Ihr Zertifikat ausschließlich für HTTPS verwenden. Browser prüfen nur die Serverauthentifizierung. Betroffen sind allein Anwendungsfälle, in denen ein öffentlich vertrauenswürdiges TLS-Zertifikat zusätzlich für Client-Authentifizierung, mTLS oder Server-zu-Server-Kommunikation eingesetzt wird.

Bedeutet das Ende von mTLS?

Nein. mTLS bleibt unverändert und gewinnt in Zero-Trust-, API- und IoT-Szenarien weiter an Bedeutung. Was sich ändert, ist die Herkunft der Client-Zertifikate: Sie stammen künftig nicht mehr aus denselben öffentlichen Hierarchien wie Serverzertifikate, sondern aus einer dafür vorgesehenen PKI.

Brauche ich dafür eine eigene Zertifizierungsstelle?

Nicht zwangsläufig. Für interne Geräte, Workloads und Microservices ist eine private PKI der naheliegende Weg. Sie können diese selbst betreiben oder als verwalteten Dienst beziehen. Sobald Systeme mehrerer Organisationen beteiligt sind, brauchen Sie einen Vertrauensanker, den alle Beteiligten akzeptieren.

Woran erkenne ich, ob ein Zertifikat beide Verwendungszwecke hat?

Werfen Sie einen Blick auf die Extended Key Usages des Zertifikats. Tauchen dort serverAuth und clientAuth gemeinsam auf, handelt es sich um ein Mehrzweckzertifikat. Genau diese Kombination wird künftig nicht mehr ausgestellt.

Wie viel Zeit bleibt für die Umstellung?

Bis zum 15. März 2027 für neu ausgestellte Endzertifikate. Praktisch ist der Spielraum kleiner: Wer heute ein Zertifikat mit einjähriger Laufzeit erneuert, steht bei der übernächsten Erneuerung bereits vor der neuen Regel. Eine Bestandsaufnahme lohnt sich deshalb jetzt.

Client-Zertifikate haben Zukunft, aber nicht als universelles Mehrzweckzertifikat

Der Titel dieses Beitrags ist bewusst etwas provokant gewählt. Denn Client-Zertifikate haben 2026 keineswegs grundsätzlich ausgedient.

Im Gegenteil: In mTLS-Architekturen, bei APIs, IoT-Geräten, Microservices und anderen Maschinenidentitäten bleiben Client- und Gerätezertifikate ein wichtiger Mechanismus zur kryptografischen Authentifizierung. Aktuelle mTLS-Lösungen setzen explizit darauf, Geräte und Services anhand von Client-Zertifikaten zu identifizieren.

Was dagegen ausgedient hat, ist der Ansatz des universellen Mehrzweckzertifikats. Spätestens am 15. März 2027 ist er technisch beendet: Ab diesem Datum enthalten neu ausgestellte öffentlich vertrauenswürdige Zertifikate ausschließlich serverAuth.

Für Unternehmen bedeutet das, ihre bestehende Zertifikatslandschaft jetzt genauer unter die Lupe zu nehmen. Wo werden Mehrzweckzertifikate eingesetzt? Wo wird clientAuth benötigt? Welche Systeme brauchen künftig eigene Geräte- oder Maschinenidentitäten? Und wie lassen sich diese Identitäten automatisiert verwalten?

Die Antwort auf den Wandel lautet deshalb nicht, Client-Zertifikate abzuschaffen, sondern sie gezielter einzusetzen. Sie sind unsicher, ob Ihre Zertifikate betroffen sind? Sprechen Sie uns an, wir prüfen Ihren Bestand gemeinsam mit Ihnen.