Über viele Jahre wurde Client Authentication (mTLS) mithilfe öffentlicher SSL/TLS-Zertifikate umgesetzt, die von allgemein vertrauenswürdigen Zertifizierungsstellen ausgestellt wurden. Dieses Modell funktionierte, weil Serverzertifikate sowohl Server Authentication als auch Client Authentication (EKU) enthalten konnten und Browser sowie Betriebssysteme dieses duale Nutzungsszenario akzeptierten.

Dieses Modell endet nun.

Gemäß den neuen Regeln der Root-Programme, insbesondere des Chrome Root Program, soll Public TLS ausschließlich der Serverauthentifizierung dienen und nicht der Client-Authentifizierung. Infolgedessen haben große öffentliche Zertifizierungsstellen begonnen, Client Authentication in öffentlichen Zertifikaten schrittweise abzuschaffen.

Für viele Organisationen bedeutet dies ein reales Risiko stiller mTLS-Ausfälle bei automatisierten Zertifikatserneuerungen.

Was ändert sich konkret?

Zeitpläne der Änderungen bei den wichtigsten Anbietern.

DigiCert

• Client Authentication EKU wird neuen öffentlichen Zertifikaten nicht mehr standardmäßig hinzugefügt.
• Die Möglichkeit zur Aktivierung wird am 1. Mai 2026 vollständig entfernt.
• Nach diesem Datum unterstützen DigiCert Public TLS Zertifikate ausschließlich Server Authentication.

Sectigo

• Sectigo stellt Client Authentication in öffentlichen TLS-Zertifikaten ein.
• Endtermin: 15. Mai 2026.
• Nach diesem Datum können weder Reissuance noch neue Zertifikate Client EKU enthalten.

Diese Änderungen sind keine Einzelentscheidungen der CAs, sondern eine direkte Folge der Richtlinien der Root-Programme, einschließlich der Anforderungen der Browser.

Warum ist dies ein operatives und nicht nur ein formales Problem?

In vielen Umgebungen läuft mTLS auf Basis öffentlicher Zertifikate seit Jahren und wurde nie neu konzipiert. Typische Beispiele sind:

• B2B- und Site-to-Site-VPNs.
• API-Gateways und Partnerintegrationen.
• SIP, VoIP und Unified Communications.
• Edge Security, Reverse Proxys und Ingress Controller.
• Ältere M2M-Integrationen, bei denen das Zertifikat die Identität darstellt.

In solchen Szenarien führt die Erneuerung eines Zertifikats ohne Client EKU zu:

• fehlgeschlagenem Verbindungsaufbau,
• Authentifizierungsfehlern auf Client-Seite,
• schwer zu diagnostizierenden Incidents nach Ablauf des alten Zertifikats.

Wichtig ist, dass diese Änderung unbemerkt eintreten kann, wenn der Erneuerungsprozess vollständig automatisiert ist.

Kurzfristige Übergangslösungen (bis 2026).

Reissuance vor dem Stichtag.

Wenn Sie derzeit Public TLS für Client Authentication nutzen, ist das Zeitfenster begrenzt.

DigiCert

• Bei Bestellung oder Neuausstellung kann Client Authentication EKU noch explizit aktiviert werden.
• Das Zertifikat kann seine Funktionalität bis zu ein Jahr nach Ausstellung behalten.
• Dies ist eine temporäre Lösung und keine strategische.

Sectigo

• Von Sectigo ausgestellte Zertifikate enthalten Client Authentication für Bestellungen seit November 2025.
• Wurde ein Zertifikat ohne EKU ausgestellt, ist eine Reissuance vor dem 15. Mai 2026 erforderlich.

Es muss jedoch klar betont werden, dass dies das Problem nur verschiebt und nicht löst.

Langfristige, zukunftssichere Lösungen.

Organisationsübergreifender Verkehr: X9 PKI.

Für B2B-, Finanz- und regulierte Umgebungen ist PKI außerhalb der Browser-Root-Programme der richtige Weg.

DigiCert X9 PKI for TLS

• Basiert auf der ASC X9 Certificate Policy und nicht auf Browser-Root-Richtlinien.
• Unterstützt sowohl Server Authentication als auch Client Authentication.
• Konzipiert für Szenarien wie:
  • organisationsübergreifende Kommunikation,
  • mTLS,
  • Integration kritischer Systeme.

Interne Systeme: Private CA / Managed PKI.

Für interne und hybride Umgebungen:

• eigene Zertifizierungsstellen,
• Managed Private CA (PKI as a Service),
• volle Kontrolle über EKUs, Richtlinien und Zertifikatslebenszyklen.

Dies ist derzeit das empfohlene Modell für:

• Kubernetes,
• Microservices,
• Zero Trust,
• Service-to-Service-Authentifizierung.

Sichtbarkeit und Automatisierung: der Schlüssel zur Sicherheit.

Unabhängig vom gewählten Modell ist die Sichtbarkeit von Zertifikaten entscheidend. Werkzeuge wie DigiCert Trust Lifecycle Manager ermöglichen es:

• alle für Client Authentication verwendeten Zertifikate zu erkennen,
• Abhängigkeiten zu identifizieren,
• Migrationspfade zu planen,
• Erneuerungen und Schlüsselrotation zu automatisieren.

Eine fehlende Zertifikatsinventarisierung ist heute eine der häufigsten Ursachen für operative Incidents.

Empfohlener Maßnahmenplan (Checkliste).

1. Alle Einsatzorte von Client Authentication identifizieren:
   • VPN, API, SIP, UC, Reverse Proxy, Edge.
2. Kurzfristige Kontinuität sicherstellen:
   • Reissuance von Zertifikaten vor den Stichtagen.
3. Zielmodell auswählen:
   • X9 PKI für organisationsübergreifenden Verkehr.
   • Private CA für interne Systeme.
4. Trust Stores aktualisieren:
   • neue Root- und Intermediate-CAs.
5. Discovery und Automatisierung aktivieren:
   • Monitoring, Alerting, Lifecycle Management.

Die Abschaffung von Client Authentication in öffentlichen SSL/TLS-Zertifikaten ist keine kurzfristige Richtlinienänderung, sondern eine dauerhafte Transformation des Vertrauensmodells im Internet. Organisationen, die weiterhin mTLS auf Basis öffentlicher SSL nutzen, müssen im Jahr 2026 architektonische Entscheidungen treffen, um Ausfälle und Sicherheitsvorfälle zu vermeiden.

Wir empfehlen, diesen Zeitpunkt als Chance zu nutzen, PKI-Strukturen zu ordnen, die Sichtbarkeit zu verbessern und ein modernes Vertrauensmodell zu implementieren, anstatt eine weitere temporäre Umgehungslösung einzusetzen.

Wenn Sie Unterstützung bei Audit, Migration oder der Auswahl des passenden PKI-Modells benötigen, steht unser Team Ihnen zur Verfügung.