Das Passwort hat ausgedient. Ist Ihr Netzwerk bereit für seinen Ersatz?
Ihre Organisation hat jahrelang die Eingangstür gesichert: Firewalls, VPNs, Multi-Faktor-Authentifizierung, Endpunktschutz. Doch eine weniger bekannte Frage ist für viele IT-Teams noch nicht abschließend beantwortet: Was passiert, wenn ein Gerät, ein Server oder ein Dienst versucht, seine Identität nachzuweisen? Es ist das, was es vorgibt zu seinWas untermauert diese Behauptung tatsächlich?
Für viele Organisationen lautet die ehrliche Antwort „ein Passwort“ oder „ein API-Schlüssel“. Und beides kann von jedem, der es in die Hände bekommt, gestohlen, per Phishing erbeutet oder nachgemacht werden.
Es gibt eine bessere Antwort, und zwar eine, die Browser und Root-Programme mittlerweile praktisch fordern: ein dediziertes Client-Authentifizierungszertifikat.
Erkunden Sie die Optionen für Clientauthentifizierungszertifikate.
Warum dies plötzlich dringend ist
Folgende Änderung hat das Problem verursacht: Seit dem 15. Juni 2026 benötigt das Root-Programm von Chrome neu ausgestellte, öffentlich vertrauenswürdige Zertifikate. TLS Serverzertifikate sollen nur noch die ServerAuth-EKU enthalten. Mozilla, Apple und Microsoft haben kompatible Stammprogrammrichtlinien eingeführt, wodurch die Verwendung von ClientAuth-EKUs in öffentlich vertrauenswürdigen Zertifikaten beendet wird. TLS Serverzertifikate.
Wenn Ihre Organisation einen Standard wiederverwendete TLS Zertifikat, das auch die Client-Authentifizierung übernimmt oder gegenseitig TLS (mTLS)Diese Abkürzung funktioniert nicht mehr. Jedes Zertifikat, das sowohl als Server- als auch als Client-Identität diente, ist für die Client-Authentifizierung nicht mehr gültig und muss durch ein speziell für diesen Zweck erstelltes Zertifikat ersetzt werden, wie es SSL bereitstellt.
Organisationen, die noch immer auf veraltete Zertifikate mit doppelter Verwendung setzen, verstoßen bereits heute gegen die Compliance-Vorgaben, und das Risiko wächst mit der Zeit. Dies betrifft alle, die zertifikatbasierte Authentifizierung für … verwenden.TLS, Zero-Trust-Zugriff, VPNs, Wi-Fi-Netzwerkzugriff, IoT-Geräte, industrielle Steuerungssysteme oder Energiemarktplattformen.
Was ein Clientauthentifizierungszertifikat tatsächlich bewirkt
Denken Sie an Ihre regelmäßigen TLS Ein Zertifikat dient als Identifikationsmerkmal Ihres Servers. Es beweist, dass der Server tatsächlich der ist, für den er sich ausgibt, wenn Ihr Browser eine Verbindung herstellt. Ein Client-Authentifizierungszertifikat kehrt diese Funktion um. Es ermöglicht einem Gerät, Benutzer, Server oder Dienst, seine Identität gegenüber dem jeweiligen Zielsystem nachzuweisen.
Die technischen Details sind hier wichtig, aber nur wegen ihrer Bedeutung für Ihr Unternehmen. Der private Schlüssel wird direkt auf dem Gerät generiert und verlässt dieses niemals. Eine öffentlich vertrauenswürdige Zertifizierungsstelle (wie z. B. SSL) signiert ausschließlich den öffentlichen Schlüssel und verknüpft ihn mit einer verifizierten Identität. Das bedeutet: Es gibt kein Passwort in einer Datenbank, das auf Phishing-Angriffe wartet, kein gemeinsames Geheimnis, das bei einem Sicherheitsvorfall preisgegeben wird, und keinen API-Schlüssel, der in ein Skript kopiert und dessen Aktualisierung vergessen wurde.
Der Widerruf funktioniert pro Zertifikat, nicht pro Geräteflotte. Geht ein Laptop verloren, endet der Zugriff eines externen Dienstleisters oder wird ein Gerät kompromittiert, widerrufen Sie einfach das entsprechende Zertifikat, und alle anderen Endgeräte funktionieren weiterhin ohne Unterbrechung.
Die wichtigsten Vorteile auf einen Blick
Das bringt Ihnen der Wechsel zu einem dedizierten Client-Authentifizierungszertifikat konkret:
- Phishing-resistente Identität. Der private Schlüssel verlässt niemals das Gerät, daher gibt es kein Passwort, das gestohlen, nachgespielt oder per Phishing ausgenutzt werden könnte.
- Chrome- und Root-Programm-kompatibel. Eine dedizierte clientAuth EKU, die die Anforderungen des CA/Browser Forums und des Root-Stores erfüllt, damit Sie nicht von der Richtlinienänderung überrascht werden, die all dies ausgelöst hat.
- Öffentlich anerkannte Hierarchie. Ausgestellt von SSLs WebTrust-geprüfter öffentlicher Plattform PKI, ohne dass eine private Root-URL über den gesamten Relying-Party-Stack verteilt werden muss.
- Drei Validierungsstufen. IV, OV und IV+OV (Sponsor), damit die Berechtigung Ihrer Identitätsrichtlinie und allen regulatorischen Anforderungen, denen Sie unterliegen, entspricht.
- Granulare Widerrufung. Entziehen Sie ein einzelnes Zertifikat, sobald ein Gerät verloren geht, außer Betrieb genommen wird oder kompromittiert ist, ohne den Rest Ihrer Geräteflotte zu beeinträchtigen.
- API-basierte Ausgabe. Heute wird das Problem über die REST-API von SSL in großem Umfang behoben, die Automatisierung mit ACME und SCEP/EST ist in Arbeit.
Zuordnung der Anmeldeinformationen zum Anwendungsfall
Die individuelle Validierung (IV) bestätigt die Identität einer namentlich genannten Person und eignet sich daher ideal für Mitarbeitergeräte, BYOD-Richtlinien und den individuellen Zugriff auf Endgeräte. Die Organisationsvalidierung (OV) bestätigt die rechtliche Existenz eines Unternehmens und ist somit für Server, virtuelle Maschinen, Servicekonten und API-Clients erforderlich. Für Situationen, in denen beides benötigt wird, beispielsweise für privilegierte Benutzer, Auftragnehmer oder in regulierten Branchen, gibt es die IV+OV (Sponsor-Validierung), die die Identität einer Person gleichzeitig mit der zugehörigen Organisation verknüpft.
Diese Flexibilität ist wichtig, weil die Client-Authentifizierung an mehr Stellen zum Einsatz kommt, als den meisten Menschen bewusst ist:
|
Luftüberwachung |
Zertifikatsstufe |
kompatibel mit |
Notizen |
|
mTLS / Zero Trust |
OV / IV+OV |
Nginx, Envoy, Istio, Kong, AWS API-Gateway |
gegenseitig TLS; beide Peers authentifizieren sich mit X.509 |
|
VPN (zertifikatsbasiert) |
IV / OV / IV+OV |
Cisco ASA/FTD, Palo Alto, Fortinet, Juniper SRX |
Eliminiert passwortbasierte VPNs; resistent gegen Phishing. |
|
Wi-Fi (802.1X / EAP-TLS) |
IV / OV |
Cisco ISE, Aruba ClearPass, Microsoft NPS |
NAC-Erzwingung; Anmeldeinformationen auf dem Gerät, nicht im Passwort |
|
IoT / Geräteidentität |
OV |
AWS IoT Core, Azure IoT Hub, kundenspezifische Broker |
Gerätespezifisches Zertifikat; individueller Widerruf ohne Neuprogrammierung der gesamten Flotte |
|
OT / SCADA / ICS |
OV |
Claroty, Nozomi, Dragos; IEC 62443-konforme Stacks |
Authentifiziert SPSen, HMIs und Historian-Knoten in OT-Netzwerken |
|
NAESB Energiemärkte |
IV+OV |
NAESB WEQ-12-kompatible Plattformen |
Erforderliche Anmeldeinformationen für OATI, PowerSecure und andere EIS-Plattformen |
|
API-Gateway-Authentifizierung |
OV / IV+OV |
Apigee, Kong, AWS API GW, Azure APIM |
Ersetzt API-Schlüssel und JWTs durch eine zertifikatsgebundene Dienstidentität |
Zusätzlich zu diesen spezifischen Anwendungsfällen funktionieren die Zertifikate umfassend in der Infrastruktur, die Ihr Team bereits betreibt:
- TLS Stapel: OpenSSL, BoringSSL, NSS, SChannel, SecureTransport, wolfSSL und mbedTLS.
- VPN und Fernzugriff: Cisco AnyConnect/SecureClient, Palo Alto GlobalProtect, Fortinet FortiClient, OpenVPN und WireGuard (über externe Authentifizierung).
- NAC und 802.1X: Cisco ISE, Aruba ClearPass, Microsoft NPS/RADIUS, FreeRADIUS und Juniper Access Control.
- API-Gateways: Kong, Nginx, Envoy, Istio, AWS API Gateway (mTLS), Azure API Management und Apigee.
- ICS und OT: IEC 62443-fähige Plattformen, einschließlich der Asset-Discovery- und Authentifizierungsschichten in Claroty, Nozomi Networks und Dragos.
Zertifikate versenden
Unabhängig davon, wie Ihre Organisation Zertifikate ausstellt, bietet SSL einen passenden Weg:
|
Methodik |
Für wen es ist |
Funktionsweise |
|
Web-Benutzeroberfläche (ssl.com Dashboard) |
IT-Administratoren, kleinere Implementierungen, einmalige Ausgabe |
Melden Sie sich bei ssl.com an, wählen Sie Client-Authentifizierung, wählen Sie die Validierungsstufe, schließen Sie die Verifizierung ab, generieren Sie das Zertifikat und laden Sie es herunter. Es sind keine Programmierkenntnisse erforderlich. |
|
REST API |
DevOps, CI/CD-Pipelines, Bereitstellung großer Flotten |
Programmatische Zertifikatsbestellung, CSR Übermittlung und Download über die dokumentierte REST-API von SSL. Unterstützt Massenausgabe und Integration mit Orchestrierungsplattformen. |
|
ACME / SCEP / EST |
Enterprise MDM, IETF-Standard-Automatisierung (geplant) |
Protokollbasierte Lebenszyklusautomatisierung über ACME (RFC 8555), SCEP und EST (RFC 7030). In Entwicklung – Informationen zu Zeitplan und Vorabzugang erhalten Sie vom Vertrieb. |
How to Buy
Client-Authentifizierungszertifikate sind direkt von SSL ohne Mindestlaufzeit erhältlich:
- Selbstbedienung. Konfigurieren und online kaufen.
- Unternehmen und Volumen. Kontaktieren Sie das SSL-Vertriebsteam für Mengenrabatte, dedizierte Kundenbetreuung und NAESB-spezifisches Onboarding.
- Private Hierarchie oder Dual-EKU-Anforderungen. Falls Sie eine private Hierarchie, ein benutzerdefiniertes Zertifikatsprofil oder ein Dual-EKU-Zertifikat benötigen, SSLs private PKI produkte (Hochsichere private Zertifikate, Dedizierte PKIund Enterprise PKI) ist der richtige Weg. Wenden Sie sich an den Vertrieb, um eine Empfehlung zu erhalten.
Fazit
Die Änderung der clientAuth-EKU war nicht nur eine technische Randnotiz. Sie war ein erzwungener Schritt, der Unternehmen dazu drängt, Serveridentität und Clientidentität endlich zu trennen und Passwörter sowie API-Schlüssel durch etwas zu ersetzen, das nicht per Phishing oder Replay angegriffen werden kann.
SSL betreibt seit über 20 Jahren eine von WebTrust geprüfte öffentliche Zertifizierungsstelle, und das Client-Authentifizierungszertifikat ist der direkte, konforme Weg für jede Organisation, die eine dedizierte Client-Identität in großem Umfang benötigt, sei es zur Sicherung eines Zero-Trust-Netzwerks, einer Flotte von IoT-Geräten oder einer von der NAESB regulierten Handelsplattform.
Wenn Sie sich nicht sicher sind, ob Ihre aktuelle Konfiguration noch ein Zertifikat mit doppelter Verwendung benötigt, sollten Sie dies jetzt überprüfen. Die Frist für die Aktualisierung ist bereits abgelaufen, daher ist die Schließung dieser Lücke zwingend erforderlich. Wir helfen Ihnen gerne dabei.
Ist dein mTLS Sind Sie von der Entfernung der clientAuth EKU betroffen? Überprüfen Sie Ihre Zertifikate auf die clientAuth EKU und sprechen Sie anschließend mit SSL über die Migration zu dedizierten Client-Authentifizierungszertifikaten (oder privaten Zertifikaten). PKI (nur für interne/Dual-EKU-Anforderungen) bevor Ihre aktuellen Zertifikate ablaufen:
