Digitale Zertifikate \u00fcbernehmen unterschiedliche Aufgaben: Sie authentifizieren Server, Clients, Ger\u00e4te oder Maschinen und schaffen damit Vertrauen in digitale Verbindungen. Lange Zeit konnten bestimmte \u00f6ffentlich vertrauensw\u00fcrdige TLS-Zertifikate neben der Serverauthentifizierung auch f\u00fcr weitere Zwecke eingesetzt werden.<\/p>\n
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.<\/p>\n
In unserem Beitrag \u201emTLS verstehen: So funktioniert mutual TLS \u2013 Grundlagen, Vorteile & Unterschiede zu klassischem TLS\u201c<\/a> haben wir bereits ausf\u00fchrlich erkl\u00e4rt, wie Mutual TLS funktioniert. In diesem Folgebeitrag gehen wir einen Schritt weiter: Was ver\u00e4ndert sich bei Client-Zertifikaten und wie sollten Unternehmen ihre Zertifikatsarchitektur k\u00fcnftig aufbauen?<\/p>\n Ein Client-Zertifikat ist ein digitales Zertifikat, mit dem ein Client seine Identit\u00e4t gegen\u00fcber einem Server kryptografisch nachweisen kann. \u201eClient\u201c bedeutet dabei keineswegs zwangsl\u00e4ufig einen Menschen beziehungsweise dessen Computer.<\/p>\n Ein Client kann beispielsweise sein:<\/p>\n Das unterscheidet Client-Zertifikate von den Zertifikaten, die wir aus dem klassischen HTTPS-Kontext kennen. Bei einer normalen TLS-Verbindung weist zun\u00e4chst der Server seine Identit\u00e4t nach. Der Browser beziehungsweise ein anderer Client pr\u00fcft dessen Zertifikat und kann feststellen, ob er tats\u00e4chlich mit dem vorgesehenen Server kommuniziert.<\/p>\n Vereinfacht dargestellt:<\/strong><\/p>\n Klassisches TLS:<\/p>\n Client \u2192 pr\u00fcft \u2192 Server-Zertifikat<\/p>\n Bei mTLS kommt eine zweite Authentifizierung hinzu:<\/p>\n Client \u2194 beide Seiten pr\u00fcfen Zertifikate \u2194 Server<\/p>\n Beide Kommunikationspartner besitzen daf\u00fcr ein Zertifikat und das zugeh\u00f6rige Schl\u00fcsselpaar. Der Server \u00fcberpr\u00fcft zus\u00e4tzlich das vom Client vorgelegte Zertifikat, bevor er den Zugriff gew\u00e4hrt. Wie sich diese Identit\u00e4ten von klassischen Benutzerkonten unterscheiden, erkl\u00e4ren wir im Beitrag \u201eMaschinenidentit\u00e4ten einfach erkl\u00e4rt\u201c<\/a>.<\/p>\n \u00d6ffentlich vertrauensw\u00fcrdige TLS-Zertifikate waren in der Vergangenheit h\u00e4ufig mit mehreren Extended Key Usages ausgestattet. Ein Zertifikat konnte dadurch beispielsweise sowohl f\u00fcr die Serverauthentifizierung (serverAuth) als auch f\u00fcr die Client-Authentifizierung (clientAuth) vorgesehen sein.<\/p>\n Diese Mehrzwecknutzung passt nicht mehr zu der Richtung, in die sich die \u00f6ffentlich vertrauensw\u00fcrdige PKI entwickelt. Mit dem Ballot SC-081v3 hat das CA\/Browser Forum im April 2025 einstimmig beschlossen, die clientAuth-EKU aus \u00f6ffentlich vertrauensw\u00fcrdigen TLS-Zertifikaten zu entfernen. Getragen wurde der Beschluss von Google, Apple, Microsoft und Mozilla sowie 25 stimmberechtigten Zertifizierungsstellen.<\/p>\n Die Umsetzung erfolgt in zwei Stufen. Zahlreiche Zertifizierungsstellen haben sie bereits vorweggenommen.<\/p>\n 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.<\/p>\n Dabei geht es ausdr\u00fccklich nicht darum, Client-Zertifikate abzuschaffen. Client-Authentifizierungszertifikate sollen lediglich nicht mehr aus denselben \u00f6ffentlichen Hierarchien stammen, denen Browser f\u00fcr die Serverauthentifizierung vertrauen. Welche Fristen im Einzelnen gelten und wer betroffen ist, haben wir im Beitrag \u201eClient-Authentifizierungs-EKU: Was sich \u00e4ndert\u201c<\/a> zusammengestellt.<\/p>\n Die Entwicklung l\u00e4sst sich auf eine einfache Formel bringen. Statt eines Zertifikats, das m\u00f6glichst viele Aufgaben gleichzeitig erf\u00fcllt, geht der Trend zu spezialisierten Zertifikatsprofilen:<\/p>\n Bisher teilweise:<\/strong><\/p>\n Ein \u00f6ffentliches Zertifikat \u2192 Serverauthentifizierung + Client-Authentifizierung + weitere Zwecke<\/p>\n Zunehmend:<\/strong><\/p>\n Server-Zertifikat \u2192 Serverauthentifizierung Diese Trennung hat einen wesentlichen Vorteil: Zertifikate lassen sich entsprechend ihres tats\u00e4chlichen Einsatzzwecks ausstellen, absichern, verwalten und mit passenden Richtlinien versehen.<\/p>\n F\u00fcr Unternehmen bedeutet das: Ein \u00f6ffentlich vertrauensw\u00fcrdiges TLS-Serverzertifikat sollte nicht automatisch als universelle digitale Identit\u00e4t f\u00fcr Server, Clients und Ger\u00e4te betrachtet werden.<\/p>\n Die technische Funktionsweise von mTLS haben wir in unserem Grundlagenbeitrag bereits ausf\u00fchrlich erl\u00e4utert. Deshalb an dieser Stelle nur die wichtigsten Punkte.<\/p>\n Bei klassischem TLS besitzt der Server ein Zertifikat. Der Client \u00fcberpr\u00fcft dieses Zertifikat und stellt anschlie\u00dfend eine verschl\u00fcsselte Verbindung her.<\/p>\n Bei mTLS kommt die Authentifizierung des Clients hinzu. Der Client besitzt ein eigenes Zertifikat und den dazugeh\u00f6rigen privaten Schl\u00fcssel. W\u00e4hrend des Verbindungsaufbaus fordert der Server das Client-Zertifikat an und \u00fcberpr\u00fcft unter anderem dessen Vertrauenskette und G\u00fcltigkeit. Der Client muss zugleich kryptografisch nachweisen, dass er den zugeh\u00f6rigen privaten Schl\u00fcssel besitzt.<\/p>\n Nur wenn die Pr\u00fcfung erfolgreich verl\u00e4uft, wird der Client als vertrauensw\u00fcrdig authentifiziert und die Verbindung entsprechend fortgesetzt.<\/p>\n Cloudflare<\/a> bringt den Unterschied auf den Punkt: W\u00e4hrend Standard-TLS die Identit\u00e4t des Servers gegen\u00fcber dem Client pr\u00fcft, erg\u00e4nzt mTLS eine zweite Pr\u00fcfung, bei der der Server die Identit\u00e4t des Clients anhand seines Client-Zertifikats verifiziert. Damit entsteht eine gegenseitig authentifizierte Verbindung.<\/p>\n W\u00e4hrend die Mehrzwecknutzung \u00f6ffentlich vertrauensw\u00fcrdiger Zertifikate zur\u00fcckgedr\u00e4ngt wird, steigt der Bedarf an dedizierten Client-Zertifikaten f\u00fcr mTLS. Verantwortlich daf\u00fcr ist vor allem die Art und Weise, wie moderne IT-Infrastrukturen aufgebaut sind.<\/p>\n Immer mehr Kommunikation findet nicht mehr zwischen einem Menschen und einer Website statt. Anwendungen kommunizieren mit APIs, Microservices tauschen untereinander Daten aus, IoT-Ger\u00e4te greifen auf Cloud-Plattformen zu und Workloads werden dynamisch gestartet und wieder beendet. In vier Bereichen ist die Entwicklung besonders deutlich.<\/p>\n Zero Trust geht davon aus, dass keiner Verbindung automatisch vertraut werden sollte, auch nicht innerhalb des eigenen Netzwerks. Jede Identit\u00e4t muss zuverl\u00e4ssig \u00fcberpr\u00fcft werden, bevor ein Zugriff gew\u00e4hrt wird.<\/p>\n mTLS liefert daf\u00fcr genau den Mechanismus, den Zero Trust ben\u00f6tigt: eine kryptografische Authentifizierung, die sich nicht durch gestohlene Zugangsdaten umgehen l\u00e4sst. Ein Client ohne g\u00fcltiges Zertifikat kommt gar nicht erst zum Verbindungsaufbau. Was hinter dem Konzept steht, erkl\u00e4ren wir im Beitrag \u201eZero Trust: kein blindes Vertrauen\u201c<\/a>.<\/p>\n APIs verbinden immer mehr Anwendungen und Dienste miteinander, h\u00e4ufig \u00fcber Unternehmensgrenzen hinweg. Klassische Zugangsdaten oder Tokens sichern dabei zwar den Zugriff ab, sie lassen sich aber kopieren und weitergeben.<\/p>\n mTLS erg\u00e4nzt eine zweite Ebene: Nur ein Client, der ein g\u00fcltiges Zertifikat und den passenden privaten Schl\u00fcssel besitzt, darf Anfragen stellen. Cloudflare setzt mTLS aus genau diesem Grund zur Authentifizierung von API-Endpunkten ein. F\u00fcr Unternehmen mit vielen angebundenen Partnern entsteht damit eine Zugriffskontrolle, die sich zentral widerrufen l\u00e4sst.<\/p>\n Moderne Anwendungen bestehen h\u00e4ufig aus Dutzenden oder Hunderten miteinander kommunizierenden Diensten. Jeder dieser Dienste muss wissen, mit welchem anderen Dienst er gerade spricht.<\/p>\n mTLS erm\u00f6glicht eine verschl\u00fcsselte 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.<\/p>\n IoT-Ger\u00e4te besitzen in aller Regel keinen klassischen Benutzer-Login. Es gibt niemanden, der ein Passwort eingibt oder einen zweiten Faktor best\u00e4tigt. Trotzdem m\u00fcssen sich diese Ger\u00e4te gegen\u00fcber Plattformen, Gateways oder anderen Ger\u00e4ten ausweisen.<\/p>\n Client- beziehungsweise Ger\u00e4tezertifikate eignen sich daf\u00fcr besonders gut: Sie h\u00e4ngen am Ger\u00e4t, nicht an einer Person, und lassen sich gezielt ausstellen und widerrufen. Cloudflare nennt IoT-Ger\u00e4te ausdr\u00fccklich als Beispiel f\u00fcr Clients, die sich per mTLS authentifizieren k\u00f6nnen, obwohl kein Identity Provider vorhanden ist.<\/p>\n Genau hier entsteht f\u00fcr viele Unternehmen der gr\u00f6\u00dfte Handlungsbedarf, denn die Zahl der Ger\u00e4te w\u00e4chst schneller als die Prozesse, die sie verwalten. Wie Zertifikate im IoT-Umfeld eingesetzt werden, beschreiben wir in den Beitr\u00e4gen \u201eIoT-Sicherheit einfach erkl\u00e4rt: die Rolle von Zertifikaten und PKI\u201c<\/a> und \u201eIoT-Ger\u00e4tezertifikate als Baustein f\u00fcr sichere Vernetzung\u201c<\/a>.<\/p>\n Damit kommen wir zur entscheidenden Botschaft: Die Zukunft von mTLS ist keineswegs mTLS ohne Client-Zertifikate. Ganz im Gegenteil.<\/p>\n Was zunehmend ausgedient hat, ist die Vorstellung, ein \u00f6ffentlich vertrauensw\u00fcrdiges TLS-Zertifikat k\u00f6nne als universelles Zertifikat f\u00fcr m\u00f6glichst viele Authentifizierungszwecke dienen.<\/p>\n F\u00fcr mTLS sollten Unternehmen stattdessen eine bewusst geplante Vertrauensarchitektur f\u00fcr Client-, Ger\u00e4te- und Maschinenidentit\u00e4ten aufbauen. Dazu geh\u00f6ren:<\/p>\n Der Punkt der Laufzeiten verdient dabei besondere Aufmerksamkeit. Seit dem 15. M\u00e4rz 2026 sinkt die maximale G\u00fcltigkeit \u00f6ffentlich vertrauensw\u00fcrdiger TLS-Zertifikate schrittweise ab. F\u00fcr eigene Client-Zertifikate lassen sich die Laufzeiten dagegen frei am Schutzbedarf ausrichten. Was die Verk\u00fcrzung im Einzelnen bedeutet, lesen Sie im Beitrag \u201eSSL-Zertifikate: Laufzeiten im Wandel\u201c<\/a>.<\/p>\n Ein Server, der \u00f6ffentlich per HTTPS erreichbar ist, ben\u00f6tigt ein Zertifikat f\u00fcr die Serverauthentifizierung. Ein Ger\u00e4t, das sich gegen\u00fcber diesem oder einem anderen Dienst ausweisen muss, erh\u00e4lt dagegen eine eigene Client- beziehungsweise Ger\u00e4teidentit\u00e4t.<\/p>\n Eine solche Architektur bedeutet nicht zwangsl\u00e4ufig, dass jedes Client-Zertifikat aus einer weltweit \u00f6ffentlich vertrauensw\u00fcrdigen PKI stammen muss.<\/p>\n Gerade f\u00fcr interne Ger\u00e4te, 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\u00fccklich f\u00fcr Anwendungsf\u00e4lle der Client-Authentifizierung.<\/p>\n Entscheidend ist deshalb nicht \u201e\u00f6ffentlich oder privat\u201c als pauschale Antwort, sondern der konkrete Vertrauensbedarf: Wer muss dem Zertifikat vertrauen, wie wird die Identit\u00e4t gepr\u00fcft 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\u00fcr solche F\u00e4lle braucht es einen Vertrauensanker, den beide Seiten akzeptieren.<\/p>\n Der Wandel hin zu klar getrennten Zertifikatszwecken ist ein guter Anlass, die eigene PKI- und Zertifikatslandschaft zu \u00fcberpr\u00fcfen. Unternehmen sollten dabei nicht nur nach ablaufenden Zertifikaten suchen, sondern vor allem untersuchen, wof\u00fcr die vorhandenen Zertifikate tats\u00e4chlich verwendet werden.<\/p>\n Am Anfang steht eine vollst\u00e4ndige Bestandsaufnahme. Unternehmen sollten feststellen, wo Client-Zertifikate vorhanden sind, welche Systeme sie einsetzen, von welcher CA sie stammen und welchen Verwendungszweck sie erf\u00fcllen.<\/p>\n Besonders in historisch gewachsenen IT-Umgebungen k\u00f6nnen Zertifikate an Stellen eingesetzt werden, die im zentralen Zertifikatsmanagement l\u00e4ngst nicht mehr bekannt sind. Welche Werkzeuge dabei helfen, zeigt unser Vergleich der Zertifikatsverwaltung<\/a>.<\/p>\n Im zweiten Schritt sollte gepr\u00fcft werden, ob Zertifikate mehrere Aufgaben gleichzeitig erf\u00fcllen. Besonders relevant ist die Frage: Wird ein \u00f6ffentlich vertrauensw\u00fcrdiges TLS-Serverzertifikat gleichzeitig f\u00fcr die Client-Authentifizierung verwendet?<\/p>\n Dabei lohnt sich ein Blick auf die Extended Key Usages. Tauchen serverAuth und clientAuth gemeinsam auf, sollte gepr\u00fcft werden, warum beide Einsatzzwecke ben\u00f6tigt werden und ob die Architektur angesichts der Fristen vom 15. Juni 2026 und 15. M\u00e4rz 2027 weiterhin tragf\u00e4hig ist.<\/p>\n Anschlie\u00dfend sollte eine klare Zertifikatsarchitektur geschaffen werden. Vereinfacht gilt:<\/p>\n Server \u2192 Server-Zertifikat Dadurch lassen sich unterschiedliche Sicherheitsanforderungen, Laufzeiten, Richtlinien und Vertrauensanker sauber trennen. F\u00fcr die Serverseite finden Sie das passende Angebot in unserer \u00dcbersicht der SSL-Zertifikate<\/a>.<\/p>\n Bei wenigen Client-Zertifikaten lassen sich viele Prozesse noch manuell beherrschen. Bei Hunderten, Tausenden oder sogar Zehntausenden Ger\u00e4ten und Workloads funktioniert das kaum noch zuverl\u00e4ssig.<\/p>\n Deshalb m\u00fcssen Unternehmen fr\u00fchzeitig kl\u00e4ren: Welche CA stellt Client-Zertifikate aus? Wie wird ein neues Ger\u00e4t registriert? Wie gelangt das Zertifikat sicher auf das Ger\u00e4t? Wo wird der private Schl\u00fcssel gespeichert? Welchen CAs vertrauen Server und Gateways? Und was geschieht, wenn ein Ger\u00e4t kompromittiert wird?<\/p>\n Damit wird mTLS von einer reinen Protokollfrage zu einer PKI- und Lifecycle-Aufgabe. Wer die Infrastruktur nicht selbst betreiben m\u00f6chte, findet in unserer Managed PKI<\/a> einen Weg, eigene Zertifikate auszustellen, ohne eine eigene Zertifizierungsstelle aufzubauen.<\/p>\n Gerade dieser letzte Punkt wird k\u00fcnftig entscheidend. Denn die zunehmende Zahl digitaler Maschinenidentit\u00e4ten f\u00fchrt zwangsl\u00e4ufig zu einer steigenden Anzahl von Zertifikaten.<\/p>\n Ausstellung, Bereitstellung, \u00dcberwachung, Erneuerung und Widerruf sollten deshalb m\u00f6glichst automatisiert erfolgen. Ein Certificate Lifecycle Management<\/a> macht Zertifikatsbest\u00e4nde zentral sichtbar und automatisiert wiederkehrende Prozesse. Die Grundlagen dazu erkl\u00e4ren wir im Beitrag \u201eGrundlagen des Zertifikatsmanagements\u201c<\/a>.<\/p>\n F\u00fcr die technische Umsetzung hat sich das ACME-Protokoll etabliert, das Zertifikate vollautomatisch beantragt, ausstellt und erneuert. Wie es funktioniert, lesen Sie im Beitrag \u201eDas ACME-Protokoll einfach erkl\u00e4rt\u201c<\/a>; das passende Werkzeug finden Sie unter ACME-Client<\/a>.<\/p>\n Ja. Die \u00c4nderungen betreffen ausschlie\u00dflich neu ausgestellte Zertifikate. Bereits ausgestellte Zertifikate bleiben bis zu ihrem Ablaufdatum g\u00fcltig. Entscheidend ist deshalb der Zeitpunkt der n\u00e4chsten Erneuerung: Ab dem 15. M\u00e4rz 2027 enth\u00e4lt ein neu ausgestelltes \u00f6ffentlich vertrauensw\u00fcrdiges Zertifikat kein clientAuth mehr.<\/p>\n Nein, sofern Sie Ihr Zertifikat ausschlie\u00dflich f\u00fcr HTTPS verwenden. Browser pr\u00fcfen nur die Serverauthentifizierung. Betroffen sind allein Anwendungsf\u00e4lle, in denen ein \u00f6ffentlich vertrauensw\u00fcrdiges TLS-Zertifikat zus\u00e4tzlich f\u00fcr Client-Authentifizierung, mTLS oder Server-zu-Server-Kommunikation eingesetzt wird.<\/p>\n Nein. mTLS bleibt unver\u00e4ndert und gewinnt in Zero-Trust-, API- und IoT-Szenarien weiter an Bedeutung. Was sich \u00e4ndert, ist die Herkunft der Client-Zertifikate: Sie stammen k\u00fcnftig nicht mehr aus denselben \u00f6ffentlichen Hierarchien wie Serverzertifikate, sondern aus einer daf\u00fcr vorgesehenen PKI.<\/p>\n Nicht zwangsl\u00e4ufig. F\u00fcr interne Ger\u00e4te, Workloads und Microservices ist eine private PKI der naheliegende Weg. Sie k\u00f6nnen diese selbst betreiben oder als verwalteten Dienst beziehen. Sobald Systeme mehrerer Organisationen beteiligt sind, brauchen Sie einen Vertrauensanker, den alle Beteiligten akzeptieren.<\/p>\n Werfen Sie einen Blick auf die Extended Key Usages des Zertifikats. Tauchen dort serverAuth<\/em> und clientAuth<\/em> gemeinsam auf, handelt es sich um ein Mehrzweckzertifikat. Genau diese Kombination wird k\u00fcnftig nicht mehr ausgestellt.<\/p>\n Bis zum 15. M\u00e4rz 2027 f\u00fcr neu ausgestellte Endzertifikate. Praktisch ist der Spielraum kleiner: Wer heute ein Zertifikat mit einj\u00e4hriger Laufzeit erneuert, steht bei der \u00fcbern\u00e4chsten Erneuerung bereits vor der neuen Regel. Eine Bestandsaufnahme lohnt sich deshalb jetzt.<\/p>\n Der Titel dieses Beitrags ist bewusst etwas provokant gew\u00e4hlt. Denn Client-Zertifikate haben 2026 keineswegs grunds\u00e4tzlich ausgedient.<\/p>\n Im Gegenteil: In mTLS-Architekturen, bei APIs, IoT-Ger\u00e4ten, Microservices und anderen Maschinenidentit\u00e4ten bleiben Client- und Ger\u00e4tezertifikate ein wichtiger Mechanismus zur kryptografischen Authentifizierung. Aktuelle mTLS-L\u00f6sungen setzen explizit darauf, Ger\u00e4te und Services anhand von Client-Zertifikaten zu identifizieren.<\/p>\n Was dagegen ausgedient hat, ist der Ansatz des universellen Mehrzweckzertifikats. Sp\u00e4testens am 15. M\u00e4rz 2027 ist er technisch beendet: Ab diesem Datum enthalten neu ausgestellte \u00f6ffentlich vertrauensw\u00fcrdige Zertifikate ausschlie\u00dflich serverAuth.<\/p>\n F\u00fcr Unternehmen bedeutet das, ihre bestehende Zertifikatslandschaft jetzt genauer unter die Lupe zu nehmen. Wo werden Mehrzweckzertifikate eingesetzt? Wo wird clientAuth ben\u00f6tigt? Welche Systeme brauchen k\u00fcnftig eigene Ger\u00e4te- oder Maschinenidentit\u00e4ten? Und wie lassen sich diese Identit\u00e4ten automatisiert verwalten?<\/p>\n 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\u00fcfen Ihren Bestand gemeinsam mit Ihnen.<\/p>\nWas sind Client-Zertifikate?<\/h2>\n
\n
Warum klassische Client-Zertifikate 2026 neu bewertet werden m\u00fcssen<\/h2>\n
Bereits erfolgt<\/h3>\n
\n
Noch offen<\/h3>\n
\n
Vom Mehrzweckzertifikat zum klar definierten Einsatzzweck<\/h3>\n
\nClient- beziehungsweise Ger\u00e4tezertifikat \u2192 Client-Authentifizierung
\nWeitere Zertifikatstypen \u2192 jeweils definierter Einsatzzweck<\/p>\nClient-Zertifikate und mTLS: So funktioniert die gegenseitige Authentifizierung<\/h2>\n
Warum mTLS 2026 immer wichtiger wird<\/h2>\n
Zero Trust<\/h3>\n
APIs<\/h3>\n
Microservices<\/h3>\n
IoT und Maschinenidentit\u00e4ten<\/h3>\n
Dedizierte Client-Zertifikate statt Mehrzweck-TLS-Zertifikate<\/h2>\n
\n
Eigene PKI f\u00fcr Client- und Maschinenidentit\u00e4ten<\/h3>\n
Client-Zertifikate 2026: Was Unternehmen jetzt tun sollten<\/h2>\n
1. Bestehende Client-Zertifikate inventarisieren<\/h3>\n
2. Verwendungszwecke und EKUs pr\u00fcfen<\/h3>\n
3. Server- und Client-Authentifizierung sauber trennen<\/h3>\n
\nClient oder Ger\u00e4t \u2192 dediziertes Client- beziehungsweise Ger\u00e4tezertifikat<\/p>\n4. Ein PKI-Konzept f\u00fcr Maschinenidentit\u00e4ten aufbauen<\/h3>\n
5. Den Zertifikats-Lifecycle automatisieren<\/h3>\n
H\u00e4ufige Fragen zu Client-Zertifikaten und mTLS<\/h2>\n
Sind meine bestehenden Client-Zertifikate weiterhin g\u00fcltig?<\/h3>\n
Ist meine Website von der \u00c4nderung betroffen?<\/h3>\n
Bedeutet das Ende von mTLS?<\/h3>\n
Brauche ich daf\u00fcr eine eigene Zertifizierungsstelle?<\/h3>\n
Woran erkenne ich, ob ein Zertifikat beide Verwendungszwecke hat?<\/h3>\n
Wie viel Zeit bleibt f\u00fcr die Umstellung?<\/h3>\n
Client-Zertifikate haben Zukunft, aber nicht als universelles Mehrzweckzertifikat<\/h2>\n