Was ändert sich und wann?

Im Artikel Client Authentication in TLS/SSL-Zertifikaten ab 2027 nicht mehr unterstützt haben wir die Änderungen des Google Chrome Root Program erläutert. Zudem haben wir aufgezeigt, welche Auswirkungen sie auf die öffentlichen TLS-Zertifikate von SwissSign haben.

Kurz gesagt: Öffentlich vertrauenswürdige TLS-Zertifikate werden künftig nur noch einem Zweck dienen, der Server-Authentifizierung. Neue Intermediate-CA-Zertifikate, die seit dem 15. Juni 2026 in der CCADB offengelegt werden, dürfen nur noch die Extended Key Usage (EKU) id-kp-serverAuth enthalten. Ab dem 15. März 2027 müssen auch neu ausgestellte öffentliche TLS-Teilnehmerzertifikate ausschliesslich id-kp-serverAuth enthalten und dürfen id-kp-clientAuth nicht mehr aufweisen.

SwissSign passt die Profile ihrer öffentlichen TLS-Zertifikate entsprechend an. Neue Profile, die ausschliesslich die Server-Authentifizierung enthalten, sind seit Ende September 2026 verfügbar. Die bisherigen Profile mit serverAuth und clientAuth werden voraussichtlich bis Ende Januar 2027 ersetzt.

Die HTTPS-Server-Authentifizierung ist davon nicht betroffen. Dieser Artikel konzentriert sich auf Anwendungsfälle der Mutual Authentication, die von der Änderung betroffen sind, sowie auf die Migration zu einer Private PKI.

Warum Server- und Client-Authentifizierung getrennt werden

Bei der Ausstellung eines öffentlichen Zertifikats wird eines geprüft: die Kontrolle über einen Domainnamen und bei OV- und EV-Zertifikaten zusätzlich die Identität der dahinterstehenden Organisation. Nicht geprüft wird hingegen, ob ein Rechner oder eine Person berechtigt ist, auf Ihr VPN, Ihr API-Gateway oder Ihre internen Dienste zuzugreifen. Ein Zertifikat, das beide Zwecke abdeckt, ist für einen Angreifer, der an den privaten Schlüssel gelangt, zudem doppelt wertvoll: Mit demselben Schlüssel kann er sich als Server ausgeben und zugleich als Client anmelden. Separate Zertifikate für die Server- und Client-Authentifizierung begrenzen die Auswirkungen kompromittierter Zugangsdaten und unterstützen ein wirksameres Risikomanagement über den gesamten Zertifikatslebenszyklus hinweg.

Welche Systeme sind betroffen?

Die Änderung betrifft in erster Linie Umgebungen, in denen öffentlich vertrauenswürdige TLS-Zertifikate für die Client-Authentifizierung eingesetzt werden. Typische Beispiele sind:

• VPN-Gateways und Remote-Zugriff: Benutzerauthentifizierung in IPsec-/IKE-VPNs, SSL-VPNs und bei Remote-Zugriffen.

• Unternehmens-WLAN und Netzwerkzugangskontrolle (802.1X): Benutzer- und Geräteauthentifizierung mit EAP-TLS für den Zugriff auf Unternehmensnetzwerke.

• API-Gateways und B2B-Integrationen: Authentifizierung von Anwendungen und API-Nutzern mittels mTLS.

• Server-to-Server-Kommunikation: Mutual Authentication zwischen Servern, Anwendungen und Systemen mittels mTLS.

• Authentifizierung von Geräten, IoT und Machine-to-Machine-Kommunikation: Maschinenauthentifizierung zur Identifizierung und Authentifizierung von Geräten, Anlagen und automatisierten Systemen.

Nicht betroffen: Wenn Ihre SwissSign TLS-Zertifikate ausschliesslich zur HTTPS-Server-Authentifizierung eingesetzt werden, etwa zur Absicherung öffentlicher Websites oder Webanwendungen, betrifft Sie diese Änderung nicht. Bestehende und künftige Server-TLS-Zertifikate funktionieren weiterhin wie bisher.

Bestehende Zertifikate funktionieren weiter, aber nicht mehr lange

Zertifikate, die vor dem Stichtag ausgestellt wurden, behalten ihre clientAuth EKU und bleiben bis zu ihrem Ablauf gültig. Damit bleibt eine gewisse Übergangszeit. Gleichzeitig werden jedoch auch die Laufzeiten öffentlicher TLS-Zertifikate kürzer: Seit März 2026 auf 200 Tage und bis 2029 auf 47 Tage. Bei jeder Erneuerung nach der Umstellung wird ein Zertifikat mit doppeltem Verwendungszweck durch ein reines serverAuth-Zertifikat ersetzt. Das Problem dabei: Eine Verbindung, die jahrelang funktioniert hat, kann nach einer routinemässigen Erneuerung plötzlich fehlschlagen. Der Ausfall zeigt sich dann im produktiven Betrieb und nicht bereits im Rahmen eines geplanten Changes.

Private PKI als Alternative für Mutual Authentication

Ein öffentliches Zertifikat ist vergleichbar mit einem Reisepass: Es wird von einer Stelle ausgestellt, der allgemein vertraut wird. Ein privates Zertifikat hingegen ist wie ein Firmenausweis: Es wird innerhalb einer klar definierten Umgebung ausgestellt und von den zugehörigen Systemen als vertrauenswürdig anerkannt. Für Mutual Authentication zwischen Systemen ist dieses private Vertrauensmodell häufig besser geeignet. Die Organisation bestimmt selbst, welche Systeme Zertifikate erhalten, wie lange diese gültig sind und wann sie widerrufen werden.

Anwendungsfall 1: mTLS in Kubernetes

In Kubernetes-Umgebungen kann eine grosse Zahl von Microservices betrieben werden, die miteinander kommunizieren. Mit mTLS werden diese Services anhand von Zertifikaten identifiziert und können sich gegenseitig authentifizieren: Jeder Service legt ein Zertifikat vor, das der empfangende Service anhand einer vertrauenswürdigen CA überprüft. Mit der Zahl der Services steigt auch die Zahl der Zertifikate, die ausgestellt, erneuert und ersetzt werden müssen. Eine Private PKI stellt dafür die private Vertrauensinfrastruktur bereit, während Certificate Lifecycle Management (CLM) die Verwaltung in grossem Umfang automatisiert. Innerhalb von Kubernetes können Tools wie cert-manager Zertifikate für einzelne Workloads anfordern und erneuern sowie an einen externen Zertifikatsaussteller angebunden werden. So lässt sich die Zertifikatsautomatisierung in Kubernetes in den übergeordneten Ansatz der Organisation für das Zertifikatsmanagement integrieren.

Anwendungsfall 2: B2B-Authentifizierung

Bei B2B-Integrationen können Organisationen mTLS einsetzen, um externe Partner zu authentifizieren, die auf ihre APIs oder Services zugreifen. Der Server weist sich gegenüber dem Partner mit seinem Zertifikat aus. Der Partner wiederum legt ein Client-Zertifikat vor, das ihn gegenüber der Organisation identifiziert. Mit einer Private PKI kann die Organisation diese Client-Zertifikate direkt an autorisierte Partner ausstellen und ihre APIs oder Gateways so konfigurieren, dass sie der privaten CA vertrauen. Damit behält die Organisation die Kontrolle darüber, welche Partner sich authentifizieren dürfen, und kann deren Zertifikate gemäss den eigenen Sicherheitsrichtlinien verwalten.

Mutual Authentication mit SwissSign Private PKI umsetzen

Mit der SwissSign Private PKI erhalten Organisationen eine dedizierte private CA, kombiniert mit Certificate Lifecycle Management, Governance und Reporting. Öffentliche und private Zertifikate lassen sich über ihren gesamten Lebenszyklus hinweg zentral verwalten.

• Schnelle Migration: Vorkonfigurierte Vorlagen, Richtlinien und Governance reduzieren den Aufwand für den Aufbau und Betrieb einer Private PKI.

• Automatisierter Zertifikatslebenszyklus: Ausstellung, Erneuerung und Verteilung von Zertifikaten lassen sich über die gesamte Infrastruktur hinweg automatisieren.

• Zentrale Zertifikatsverwaltung: Öffentliche und private Zertifikate können einschliesslich Ausstellung und Widerruf über eine zentrale Plattform verwaltet werden.

• Stärkere Kontrolle: Einheitliche Zertifikatsrichtlinien, Governance und Reporting schaffen klare Vorgaben für die Client-Authentifizierung.

• Planbare Kosten: CHF 2'025.– pro Jahr und CHF 31.80 pro Zertifikat und Jahr.

Eine private Hierarchie bietet zudem eine kontrollierte Umgebung, um sich auf künftige kryptografische Veränderungen vorzubereiten, darunter die Einführung von Post-Quanten-Algorithmen.Für die Authentifizierung von Personen gelten andere Anforderungen. Je nach Anwendungsfall können Sponsor-validated S/MIME-Zertifikate ab der Validierungsstufe Organization Validation (OV) im Rahmen einer Managed PKI eine Alternative sein.

Drei Schritte, die Sie jetzt unternehmen sollten

1. Bestandsaufnahme durchführen: Prüfen Sie Ihren Zertifikatsbestand nach der clientAuth EKU und identifizieren Sie jedes System, das ein Zertifikat als Client vorlegt. Anhand der Erneuerungsdaten allein lässt sich nicht erkennen, welche Systeme clientAuth verwenden.
2. Für jeden Anwendungsfall entscheiden: Bestimmen Sie für jedes Client-Authentifizierungsszenario die passende Alternative, etwa eine Private PKI für Maschinen, Services und Geräte oder S/MIME-Zertifikate, wenn eine Benutzerauthentifizierung erforderlich ist.
3. Automatisieren: Bei kürzeren Laufzeiten ist ein manueller Austausch nicht mehr skalierbar. Certificate Lifecycle Management automatisiert die Erkennung, Erneuerung und Verteilung von Zertifikaten und löst damit beide Herausforderungen zugleich.

Häufig gestellte Fragen