Was ist ein X.509-Zertifikat? Der umfassende Leitfaden zum Thema digitales Vertrauen

Da Unternehmen heute mehr Maschinen, Geräte und Dienste verwalten als je zuvor, ist die Anzahl der im Einsatz befindlichen X.509-Zertifikate exponentiell gestiegen. Gleichzeitig verkürzt diebevorstehende Umstellung auf eine Zertifikatslaufzeit von 47 Tagendie Zeitfenster für die Erneuerung, wodurch eine manuelle Zertifikatsverwaltung nicht mehr tragbar ist. Für IT- und Sicherheitsteams ist es mittlerweile unerlässlich zu verstehen, wie X.509-Zertifikate funktionieren, wie sie verwaltet werden und wie man sich auf neue kryptografische Standards vorbereitet.

Dieser Leitfaden behandelt alles, was Sie über X.509-Zertifikate wissen müssen: Was sie sind, wie sie die Kommunikation sichern, wie sie intern aufgebaut sind, bewährte Verfahren für das Lebenszyklusmanagement und was der Übergang zur postquantenkryptografie für Ihre Zertifikatsstrategie bedeutet.

Was ist ein X.509-Zertifikat?

Ein X.509-Zertifikat ist ein digitales Zertifikat, das dem Standard der ITU-Empfehlung X.509 entspricht und im RFC 5280 auch als Internetstandard übernommen wurde. Es dient in erster Linie dazu, die Identität festzustellen und die Kommunikation über Netzwerke hinweg zu sichern. Es verknüpft eine verifizierte Identität (wie beispielsweise einen Domainnamen, eine Organisation oder ein Gerät) mit einem kryptografischen Schlüsselpaar, wodurch sich Systeme gegenseitig authentifizieren und Daten während der Übertragung verschlüsseln können.

X.509-Zertifikate dienen sowohl als Identitätsnachweis für Maschinen als auch für menschliche Nutzer, wobei die Kommunikation zwischen Maschinen der mit Abstand häufigste Anwendungsfall ist. Sie bilden das Rückgrat mehrerer wichtiger Sicherheitsprotokolle und -anwendungen:

• TLS Websicherheit):Jede HTTPS-Verbindung basiert auf einem X.509-Zertifikat, um den Server zu authentifizieren und einen verschlüsselten Kanal herzustellen.
• S/MIME (E-Mail-Sicherheit):X.509-Zertifikate verschlüsseln und signieren E-Mail-Nachrichten digital und gewährleisten so Vertraulichkeit und Absenderüberprüfung.
• Code-Signierung:Software verwenden X.509-Zertifikate, um ausführbare Dateien und Updates zu signieren und damit nachzuweisen, dass der Code nicht manipuliert wurde.
• Geräteauthentifizierung:IoT , industrielle Steuerungen und Netzwerkgeräte verwenden X.509-Zertifikate, um ihre Identität in einem Netzwerk nachzuweisen.

Bemerkenswert ist, dass SSH in der obigen Liste nicht aufgeführt ist, da das Protokoll einen anderen Zertifikatstyp verwendet, um die Anforderungen des Protokolls nativ zu unterstützen.

X.509-Zertifikate werden im Rahmen einer Public-Key-Infrastruktur (PKI) eingesetzt, in der Zertifizierungsstellen (CAs) Zertifikate gemäß festgelegten Vertrauensrichtlinien ausstellen, validieren und widerrufen. Während die PKI das übergeordnete Vertrauensrahmenwerk definiert und die CAs darin als vertrauenswürdige Dritte fungieren, legt der X.509-Standard das genaue Format und die Felder fest, die ein Zertifikat system- und anwendungsübergreifend interoperabel machen.

Andere Arten von Zertifikaten, wie beispielsweise PGP-Zertifikate, basieren auf einem dezentralen „Web of Trust“-Modell, bei dem jeder Nutzer für die Identität eines anderen bürgen kann. X.509-Zertifikate hingegen stützen sich auf ein hierarchisches Vertrauensmodell, an dessen Spitze etablierte Zertifizierungsstellen (CAs) stehen. Dieser hierarchische Ansatz lässt sich besser auf Anwendungsfälle in Unternehmen und im Internet skalieren, wo zentralisierte Vertrauensentscheidungen und automatisierte Validierung unerlässlich sind.

Wie X.509-Zertifikate die Kommunikation sichern

Die bekannteste Anwendung von X.509-Zertifikaten ist die Sicherung des Webverkehrs über das TLS Transport Layer Security), das früher als SSL bekannt war. Ein Blick auf den TLS verdeutlicht, wie Zertifikate eine vertrauenswürdige, verschlüsselte Kommunikation ermöglichen.

Der TLS -Prozess

Wenn ein Client (z. B. ein Webbrowser) eine Verbindung zu einem Server herstellt, folgt der TLS einer festgelegten Abfolge. Die genauen Schritte variieren je nach Version, lassen sich jedoch im Großen und Ganzen wie folgt beschreiben:

1. Client-Hello:Der Client initiiert die Verbindung, indem er dem Server seine unterstützten Verschlüsselungssuiten und TLS zusammen mit einem Nonce übermittelt.
2. Vorlage des Serverzertifikats:Der Server antwortet mit seinem signierten X.509-Zertifikat und legt dem Client damit seine verifizierte Identität vor, zusammen mit einer Signatur des Nonce.
3. Zertifikatsvalidierung:Der Client überprüft die Signatur des Nonce mit dem öffentlichen Schlüssel im Zertifikat und die Signatur des Zertifikats, indem er diese über die Zertifikatskette bis zu einer vertrauenswürdigen Stamm-Zertifizierungsstelle in seinem Vertrauensspeicher zurückverfolgt. Dadurch wird bestätigt, dass der Server tatsächlich der ist, für den er sich ausgibt.
4. Schlüsselaustausch:Sobald die Authentifizierung erfolgreich abgeschlossen ist, vereinbaren Client und Server einen gemeinsamen symmetrischen Schlüssel. Mit diesem Schlüssel werden alle nachfolgenden Daten in der Sitzung verschlüsselt.
5. Sicherer Kanal hergestellt:Sobald der symmetrische Schlüssel festgelegt ist, kommunizieren Client und Server über einen verschlüsselten Kanal, wodurch die Daten vor Abfangen oder Manipulation geschützt sind.

Server- und Client-Authentifizierung

Bei TLS meisten TLS legt nur der Server ein Zertifikat vor, das vom Client überprüft wird. Dies ist der Standardablauf beim Surfen über HTTPS: Der Server weist seine Identität nach, und der Client (Browser) überprüft diese, bevor er fortfährt. In einigen Umgebungen ist es jedoch erforderlich, dass sich beide Parteien gegenseitig authentifizieren – mittels Mutual TLS mTLS), bei dem der Server auch das X.509-Zertifikat des Clients überprüft. Mutual TLS zunehmend Anwendung in der API-Sicherheit, in Zero-Trust-Architekturen und in industriellen Umgebungen, in denen beide Endpunkte ihre Identität nachweisen müssen, bevor sie Daten austauschen.

Die Rolle digitaler Signaturen

Die digitale Signatur des X.509-Zertifikats ist die Grundlage für das gesamte Vertrauensmodell. Zunächst kann der Client sicherstellen, dass er mit dem Inhaber des Zertifikats kommuniziert, indem er überprüft, ob der Nonce korrekt signiert wurde; das Zertifikat allein reicht nicht aus, da jeder Zugriff darauf haben kann. Der Client kann sich zudem vergewissern, dass der Server der Eigentümer des Zertifikats ist. Wenn eine Zertifizierungsstelle (CA) ein Zertifikat ausstellt, signiert sie die Zertifikatsdaten mit ihrem eigenen privaten Schlüssel. Der Client kann diese Signatur mithilfe des öffentlichen Schlüssels der CA (der über die Zertifikatskette verfügbar ist) überprüfen und so bestätigen, dass das Zertifikat nicht verändert wurde und tatsächlich von der angegebenen Stelle ausgestellt wurde.

X.509-Zertifikatsformat und -Felder

Der X.509-Standard definiert eine genau festgelegte Reihe von Feldern, die jedes Zertifikat enthalten muss. Diese Felder liefern die Informationen, anhand derer Clients und Server Identitäten überprüfen und Vertrauen aufbauen.

Kernfelder des Zertifikats

Feld	Beschreibung
Version	Die X.509-Versionsnummer (V1, V2 oder V3). Wird diese Angabe weggelassen, wird von Version 1 ausgegangen.
Seriennummer	Eine eindeutige Kennung, die von der ausstellenden Zertifizierungsstelle vergeben wird. Keine zwei Zertifikate derselben Zertifizierungsstelle haben dieselbe Seriennummer.
Signaturalgorithmus	Der Algorithmus, der zur Erstellung der digitalen Signatur des Zertifikats verwendet wurde.
Emittent	Der Distinguished Name (DN) der Zertifizierungsstelle, die das Zertifikat ausgestellt hat.
Gültigkeit	Zwei Zeitstempel, die den Gültigkeitszeitraum des Zertifikats definieren: „Not Before“ (Beginn der Gültigkeit) und „Not After“ (Ablaufdatum).
Betreff	Der eindeutige Name der Entität, die durch das Zertifikat identifiziert wird (z. B. ein Domainname oder eine Organisation).
Betreff: Informationen zum öffentlichen Schlüssel	Der Algorithmus für den öffentlichen Schlüssel (RSA, DSA oder Diffie-Hellman) und der eigentliche Wert des öffentlichen Schlüssels.

Erweiterungen für Version 3

Mit den Zertifikaten der Version 3 wurden Erweiterungen eingeführt, die den Informationsumfang eines Zertifikats erheblich erweitern. Diese Erweiterungen nutzen drei Unterfelder:

• extnId:Identifiziert die jeweilige Erweiterung.
• critical:Ein boolescher Flag, der angibt, ob die Erweiterung für die Verarbeitung durch den Empfänger zwingend erforderlich ist. Wird eine als „critical“ gekennzeichnete Erweiterung nicht erkannt, muss das Zertifikat abgelehnt werden.
• extnValue:Enthält die Erweiterungsdaten, kodiert als Oktett-Zeichenkette.

Zu den gängigen V3-Erweiterungen gehören Einschränkungen der Schlüsselverwendung (die festlegen, welche Vorgänge mit einem Schlüssel durchgeführt werden dürfen), alternative Namen des Zertifikatsinhabers (wodurch ein einzelnes Zertifikat mehrere Domänen abdecken kann), Zertifikatsrichtlinien und grundlegende Einschränkungen (die CA-Zertifikate von Endentitätszertifikaten unterscheiden).

Diese Erweiterungen sind für den modernen PKI-Betrieb unverzichtbar und ermöglichen eine detaillierte Steuerung der Verwendung von Zertifikaten innerhalb und über Vertrauensdomänen hinweg.

X.509-Zertifikatskodierung: DER vs. PEM

Der X.509-Standard definiert den Inhalt und die Struktur eines Zertifikats, schreibt jedoch nicht vor, wie diese Daten zur Speicherung und Übertragung kodiert werden sollen. In der Praxis setzen sich zwei Kodierungsformate durch.

DER (Distinguished Encoding Rules)

DER ist ein binäres Kodierungsformat, mit dem kompakte Zertifikatsdateien erstellt werden. DER-kodierte Zertifikate lassen sich nicht in einem Texteditor öffnen, werden jedoch von Webbrowsern, Betriebssystemen und Java-basierten Anwendungen effizient verarbeitet. Zu den gängigen Dateiendungen für DER-kodierte Zertifikate gehören .der und .cer.

PEM (Privacy Enhanced Mail)

PEM wandelt DER-kodierte Binärdaten in Base64-kodierten Text um, sodass das Zertifikat in jedem Texteditor gelesen werden kann. PEM-Dateien sind an ihren charakteristischen Kopf- und Fußzeilen zu erkennen:

-----BEGIN CERTIFICATE----- [Base64-kodierte Daten]  —–ENDE DES ZERTIFIKATS—–`

PEM ist das gängigste Format auf Linux- und Unix-Systemen, auf Webservern (Apache, Nginx) sowie in command wie OpenSSL. Zu den gängigen Dateiendungen gehören .pem und .crt.

Die Wahl zwischen den Formaten

Beide Formate enthalten identische Zertifikatsdaten; der Unterschied liegt ausschließlich in der Darstellung. DER wird in Umgebungen bevorzugt, in denen es auf die Effizienz bei der Verarbeitung von Binärdaten ankommt (eingebettete Systeme, bestimmte Windows-Anwendungen). PEM wird bevorzugt, wenn Zertifikate über textbasierte Protokolle übertragen werden müssen (E-Mail, Konfigurationsdateien, Copy-Paste-Workflows).

Die Konvertierung zwischen den Formaten ist mit Standardtools wie OpenSSL oder certutil unkompliziert, sodass sich Zertifikate problemlos an unterschiedliche Systemanforderungen anpassen lassen.

Versionshistorie von X.509

Der X.509-Standard hat sich über drei Hauptversionen hinweg weiterentwickelt, wobei mit jeder Version die Funktionen des Zertifikats erweitert wurden, um den Anforderungen immer komplexerer Netzwerkumgebungen gerecht zu werden.

Version 1 (1988)

Die ursprüngliche X.509-Spezifikation führte die Kernstruktur von Zertifikaten mit den oben beschriebenen Grundfeldern ein. Die Distinguished Names folgten den Regeln des X.500-Verzeichnisstandards, der sich an den hierarchischen Systemen orientierte, die weltweit zur Vergabe von Telefonnummern verwendet wurden.

Version 2 (1993)

In Version 2 wurden zwei Felder hinzugefügt: „Issuer Unique Identifier“ und „Subject Unique Identifier“. Diese Felder waren dafür gedacht, Fälle zu berücksichtigen, in denen Aussteller oder Zertifikatsinhaber im Laufe der Zeit Distinguished Names wiederverwenden könnten. Die IETF betrachtet diese Felder nun jedoch als veraltet, und sie sollten in neuen Zertifikaten nicht mehr verwendet werden. Das rasante Wachstum des Internets in dieser Zeit führte zu einer steigenden Nachfrage nach einer flexibleren Zertifikatsstruktur.

Version 3 (ab 1996)

Mit Version 3 wurde das Erweiterungs-Framework eingeführt, das es ermöglicht, dass Zertifikate zusätzliche Informationen über die Schlüsselverwendung, Zertifikatsrichtlinien, alternative Namen des Zertifikatsinhabers, Namensbeschränkungen und vieles mehr enthalten können. Diese Erweiterbarkeit verwandelte X.509 von einem einfachen Identitätsnachweis in ein vielseitiges Werkzeug, das komplexe Vertrauensbeziehungen innerhalb und zwischen PKI-Domänen unterstützen kann. Die Standardisierung wurde 1996 von der IETF abgeschlossen, jedoch erst 1997 von der ITU-T offiziell genehmigt.

Heutzutage sind praktisch alle im Einsatz befindlichen Zertifikate der Version 3. Das Erweiterungsframework hat sich als unverzichtbar erwiesen, um moderne Anwendungsfälle wie Multi-Domain-Zertifikate, Einschränkungen bei der Codesignierung unddie im Laufe der Zeit veränderten Gültigkeitsdauer von Zertifikaten zu unterstützen.

Vertrauensketten und Zertifizierungsstellen

X.509-Zertifikate basieren auf hierarchischen Vertrauensketten, die es einem Client ermöglichen, jedes Zertifikat zu überprüfen, indem er es bis zu einer vertrauenswürdigen Stammzertifizierungsstelle zurückverfolgt. Eine typische Kette umfasst drei Ebenen:

• ein selbstsigniertes Root-CA-Zertifikat (vorinstalliert in den Vertrauensspeichern des Browsers und des Betriebssystems),
• ein Zwischenzertifikat einer Zertifizierungsstelle, das die alltäglichen Aufgaben der Signierung von Endbenutzerzertifikaten übernimmt, während der private Schlüssel der Stammzertifizierungsstelle sicher offline aufbewahrt wird, und
• das Endzertifikat, das von einer Website, einem Server oder einem Gerät vorgelegt wird.

Wenn ein Client ein Endentitätszertifikat erhält, durchläuft er die Zertifikatskette von unten nach oben und überprüft dabei jede Signatur, bis er eine vertrauenswürdige Stammzertifizierungsstelle erreicht. Das Zertifikat wird nur akzeptiert, wenn alle Signaturen gültig sind. Die Vertrauensspeicher variieren je nach Client: Firefox unterhält einen eigenen mit etwa 150 Stammzertifikaten, während Chrome auf den Vertrauensspeicher des Betriebssystems zurückgreift – mit Ausnahmen wie seiner separaten Liste „EV-Qualified“-Stammzertifikate und seiner seit 2015 geltenden Anforderung an die Zertifikatstransparenz für Extended-Validation-Zertifikate (EV).

Vertrauen kann durch gegenseitige Zertifizierung auch über Organisationsgrenzen hinweg reichen. Dabei signieren zwei Stamm-Zertifizierungsstellen gegenseitig ihre Zertifikate, sodass Clients, die einer Stamm-Zertifizierungsstelle vertrauen, auch die von der anderen ausgestellten Zertifikate akzeptieren – ähnlich wie bei internationalen Telefonvereinbarungen, die die Reichweite über Ländervorwahlen hinaus erweitern. Über die Kettenstruktur hinaus stellen Zertifizierungsstellen Zertifikate auf verschiedenen Validierungsstufen aus, die widerspiegeln, wie gründlich die Identität überprüft wird:

• Domain-Validierung (DV):Bestätigt, dass der Antragsteller die Kontrolle über die Domain hat. Schnelle Ausstellung, minimaler Überprüfungsaufwand.
• Organisationsvalidierung (OV):Bestätigt die Domain und überprüft die rechtliche Identität der Organisation.
• Extended Validation (EV):Die strengste Validierungsstufe, bei der die Identität, der Rechtsstatus und die physische Adresse der Organisation eingehend überprüft werden. EV-Zertifikate lösen in einigen Browsern erweiterte Vertrauensindikatoren aus.

So erstellen Sie ein X.509-Zertifikat

Die Erstellung eines X.509-Zertifikats erfolgt nach einem genau festgelegten Verfahren, unabhängig davon, ob Sie ein von einer Zertifizierungsstelle ausgestelltes Zertifikat für den Produktivbetrieb oder ein selbstsigniertes Zertifikat für Entwicklungszwecke erstellen.

Der Arbeitsablauf zur Zertifikatserstellung

1. Schlüsselpaar generieren:Erstellen Sie ein öffentliches/privates Schlüsselpaar unter Verwendung eines unterstützten Algorithmus (RSA, ECDSA oder Ed25519). Der private Schlüssel muss sicher aufbewahrt und darf niemals weitergegeben werden.
2. Erstellen Sie eine Zertifikatssignierungsanforderung (CSR):Die CSR enthält den öffentlichen Schlüssel sowie die Identifikationsdaten (Name des Zertifikatsinhabers, Organisation usw.), die im Zertifikat erscheinen werden. Die CSR wird mit dem privaten Schlüssel des Antragstellers signiert, um den Besitz nachzuweisen.
3. Reichen Sie die CSR bei einer Zertifizierungsstelle ein:Für Produktionszertifikate reichen Sie die CSR bei einer vertrauenswürdigen Zertifizierungsstelle ein. Die Zertifizierungsstelle überprüft die Identität des Antragstellers entsprechend der gewählten Validierungsstufe (DV, OV oder EV).
4. Erhalt des signierten Zertifikats:Die Zertifizierungsstelle signiert das Zertifikat mit ihrem eigenen privaten Schlüssel und gibt das fertige X.509-Zertifikat zurück, das nun einsatzbereit ist.

Tools zur Zertifikatserstellung

• OpenSSL:Das am häufigsten verwendete command zum Generieren von Schlüsseln, Erstellen von CSRs und Verwalten von Zertifikaten. OpenSSL ist auf praktisch jedem Linux- und macOS-System verfügbar.
• EJBCA:Die open-source Keyfactor, die für die Ausstellung und Verwaltung von Zertifikaten im Unternehmensmaßstab konzipiert ist. EJBCA die automatisierte Registrierung über Standardprotokolle.
• Registrierungsprotokolle:Standards wie SCEP (Simple Certificate Enrollment Protocol), CMP (Certificate Management Protocol), EST (Enrollment over Secure Transport) und ACME (Automated Certificate Management Environment) ermöglichen die automatisierte Zertifikatsausstellung und reduzieren so manuelle Eingriffe und menschliche Fehler.

Selbstsignierte Zertifikate im Vergleich zu von einer Zertifizierungsstelle ausgestellten Zertifikaten

Selbstsignierte Zertifikate können vollständig vom Endbenutzer ohne Einbeziehung einer Zertifizierungsstelle (CA) erstellt werden. Sie eignen sich für Entwicklungs-, Test- und interne Laborumgebungen. In der Produktion sollten selbstsignierte Zertifikate jedoch niemals verwendet werden. Dies wird in den folgenden Abschnitten erläutert.

So überprüfen Sie das Ablaufdatum von X.509-Zertifikaten

Abgelaufene Zertifikate führen zu Dienstausfällen, Beeinträchtigungen der Benutzererfahrung und Sicherheitslücken. Die Überwachung des Ablaufs von Zertifikaten ist eine entscheidende betriebliche Maßnahme, insbesondere angesichts immer komplexer werdender Umgebungen.

Warum die Überwachung des Verfallsdatums wichtig ist

Zertifikate verfügen über integrierte Gültigkeitszeiträume, die durch die Felder „notBefore“ und „notAfter“ definiert sind. Wenn ein Zertifikat abläuft, schlägt jede Verbindung, die darauf basiert, fehl. In Webumgebungen lösen abgelaufene Zertifikate Browserwarnungen aus, die den Zugriff der Benutzer auf die Website blockieren. In industriellen Umgebungen können abgelaufene Zertifikate auf SPSen, HMIs oder Edge-Gateways Produktionslinien vollständig zum Stillstand bringen.

Unternehmen, die auf manuelle Nachverfolgung (Tabellenkalkulationen, Kalendererinnerungen) setzen, sind immer wieder mit vermeidbaren Ausfällen konfrontiert. Die Herausforderung wächst mit der Anzahl der Zertifikate: Ein einziges übersehenes Ablaufdatum in einer Flotte von Tausenden kann eine Kettenreaktion auslösen, die zu einem schwerwiegenden Vorfall führt.

Verfahren zur Überprüfung des Verfallsdatums

Überprüfung im Browser:Klicken Sie auf das Vorhängeschloss-Symbol in der Adressleiste Ihres Browsers, um die Zertifikatsdetails einschließlich des Ablaufdatums anzuzeigen. Dies funktioniert bei jeder HTTPS-Website, ist jedoch für die Überwachung umfangreicher Zertifikatsbestände unpraktisch.

Command:OpenSSL bietet direkten Zugriff auf die Ablaufdaten von Zertifikaten:

openssl x509 -enddate -noout -in certificate.pem

Dadurch wird das „Not After“-Datum in einem für Menschen lesbaren Format zurückgegeben. Bei Remote-Servern können Sie das Ablaufdatum überprüfen, ohne das Zertifikat herunterzuladen:

openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -enddate

Automatisierte Überwachungslösungen:In Produktionsumgebungen scannen Tools zur automatisierten Erkennung und Überwachung von Zertifikaten kontinuierlich die Netzwerke, erfassen alle Zertifikate und benachrichtigen die Administratoren, bevor deren Ablaufdatum erreicht ist. Dieser Ansatz beseitigt das Risiko menschlicher Versäumnisse und ist für Unternehmen, die Hunderte oder Tausende von Zertifikaten verwalten, unverzichtbar.

Selbstsignierte vs. von einer Zertifizierungsstelle ausgestellte X.509-Zertifikate

Die Wahl zwischen selbstsignierten und von einer Zertifizierungsstelle ausgestellten Zertifikaten hat erhebliche Auswirkungen auf die Sicherheit, die Verwaltbarkeit und das Vertrauen.

Was macht selbstsignierte Zertifikate so riskant?

Ein selbstsigniertes Zertifikat ist ein Zertifikat, bei dem der Aussteller und der Zertifikatsinhaber dieselbe Stelle sind. Der Zertifikatsinhaber generiert das Schlüsselpaar, erstellt das Zertifikat und signiert es mit seinem eigenen privaten Schlüssel. Es findet keine Überprüfung durch Dritte statt.

Umgangssprachlich ausgedrückt ist die Verwendung eines selbstsignierten Zertifikats so, als würde man seinen eigenen Reisepass ausstellen. Man kann es zwar vorlegen, und es mag echt aussehen, aber keine vertrauenswürdige Stelle hat die Identität des Vorlegenden überprüft. Jedes System, das ein selbstsigniertes Zertifikat akzeptiert, vertraut der Aussage des Vorlegenden, ohne diese unabhängig zu überprüfen.

Zu den Risiken selbstsignierter Zertifikate im Produktivbetrieb gehören:

• Keine Vertrauensüberprüfung:Ohne eine Zertifizierungsstelle in der Kette gibt es keine unabhängige Bestätigung dafür, dass der Zertifikatsinhaber tatsächlich der ist, für den er sich ausgibt. Man-in-the-Middle-Angriffe lassen sich dadurch leichter durchführen.
• Nicht verwaltete Gültigkeitsdauer:Wenn jemand mithilfe eines command ein selbstsigniertes Zertifikat erstellt, entspricht das Ablaufdatum dem Wert, den er bei der Erstellung eingegeben hat. Ohne zentrale Nachverfolgung laufen diese Zertifikate ohne Vorwarnung ab.
• Betriebsausfälle:Unternehmen berichten immer wieder von Ausfällen, die durch abgelaufene, selbstsignierte Zertifikate verursacht werden. In industriellen Umgebungen haben abgelaufene Zertifikate auf OPC-UA-Servern, HMIs und SPSen dazu geführt, dass Maschinen ihren Betrieb einstellten, was sich unmittelbar auf die Produktion und den Umsatz auswirkte.

Wann sind selbstsignierte Zertifikate sinnvoll?

Selbstsignierte Zertifikate sind in kontrollierten, nicht produktiven Szenarien zulässig:

• Lokale Entwicklungs- und Testumgebungen
• Interne Laboraufbauten, die von den Produktionsnetzwerken isoliert sind
• Proof-of-Concept-Demonstrationen

Root-CA-Zertifikate sind ebenfalls selbstsigniert, doch dies ist eine strukturelle Eigenschaft von Vertrauensankern und kein gleichwertiger Fall. Sie sind in der Produktion auf jeder Sicherheitsstufe angemessen (ja sogar erforderlich), wobei das Vertrauen durch die Verteilung in Vertrauensspeicher und nicht durch die Signatur selbst begründet wird.

Warum von einer Zertifizierungsstelle (CA) ausgestellte Zertifikate für den Produktivbetrieb unverzichtbar sind

Von einer Zertifizierungsstelle (CA) ausgestellte Zertifikate bilden die Vertrauenskette, auf die sich Browser, Betriebssysteme und Anwendungen stützen, um Identitäten automatisch zu überprüfen. Die Zertifizierungsstelle hat die Identität des Zertifikatsinhabers überprüft, das Zertifikat lässt sich bis zu einer vertrauenswürdigen Stammzertifizierungsstelle zurückverfolgen, und das Ablaufdatum wird im Rahmen eines verwalteten Lebenszyklus überwacht. Für jedes System, das externe Benutzer bedient, sensible Daten verarbeitet oder eine Verbindung zur Produktionsinfrastruktur herstellt, sind von einer Zertifizierungsstelle ausgestellte Zertifikate zwingend erforderlich.

Verwaltung des Lebenszyklus von X.509-Zertifikaten

Die Verwaltung von X.509-Zertifikaten ist keine einmalige Aufgabe. Jedes Zertifikat durchläuft einen Lebenszyklus, der – wenn er nicht aktiv verwaltet wird – Sicherheitsrisiken und Betriebsstörungen mit sich bringt.

Die Phasen des Zertifikatslebenszyklus

1. Erfassung:Identifizieren Sie alle Zertifikate in der gesamten Umgebung, einschließlich derjenigen, die von mehreren Zertifizierungsstellen ausgestellt, in Geräte eingebettet oder von einzelnen Teams ohne zentrale Überwachung bereitgestellt wurden.
2. Bestandsaufnahme:Erfassen Sie jedes Zertifikat mit seinen Metadaten: Aussteller, Betreff, Ablaufdatum, Schlüsselalgorithmus und Einsatzort.
3. Ausstellung:Beantragung und Erhalt von Zertifikaten bei den zuständigen Zertifizierungsstellen unter Verwendung standardisierter Registrierungsprotokolle.
4. Bereitstellung:Installieren Sie die Zertifikate auf den Zielsystemen (Webserver, Load Balancer, Geräte, Anwendungen).
5. Überwachung:Kontinuierliche Überwachung des Zertifikatsstatus, bevorstehender Ablaufdaten und der Einhaltung von Richtlinien.
6. Verlängerung:Ersetzen Sie Zertifikate vor ihrem Ablauf, idealerweise mithilfe automatisierter Workflows.
7. Widerruf:Zertifikate, die kompromittiert wurden, nicht mehr benötigt werden oder mit stillgelegten Systemen in Verbindung stehen, sind für ungültig zu erklären.

Warum manuelle Verwaltung bei großem Umfang scheitert

Unternehmen, die versuchen, Zertifikate mithilfe von Tabellenkalkulationen, E-Mail-Erinnerungen oder Ad-hoc-Prozessen zu verwalten, stoßen immer wieder auf dieselben Probleme: übersehene Ablauftermine, Doppelarbeit, uneinheitliche Durchsetzung von Richtlinien und verzögerte Reaktion auf Vorfälle. Diese Herausforderungen verschärfen sich mit steigendem Zertifikatsvolumen und kürzer werdenden Gültigkeitsfristen.

Die Umstellung aufeine Gültigkeitsdauer von 47 Tagen für Zertifikate und die Dringlichkeit der Automatisierungmachen eine manuelle Verwaltung unhaltbar. Wenn Zertifikate alle 47 Tage statt alle 398 Tage erneuert werden, steigt der operative Aufwand für die Erneuerungen um etwa das Achtfache.

Die Rolle der Automatisierung

Das automatisierte Zertifikatslebenszyklusmanagement bewältigt diese Herausforderungen durch:

• Kontinuierliche Erfassung von Zertifikaten in Netzwerken, Cloud-Umgebungen und Geräteflotten
• Registrierung und Verlängerung von Zertifikaten über Standardprotokolle (SCEP, CMP, EST, ACME)
• Durchsetzung einheitlicher Richtlinien für alle Zertifikatstypen und Zertifizierungsstellen
• Warnungen bei bevorstehenden Ablaufterminen und Richtlinienverstößen, bevor diese zu Vorfällen führen
• Unterstützung von Standard-Zertifikatsformaten (PKCS#7, PKCS#10, PKCS#12, PEM) zur plattformübergreifenden Interoperabilität

In industriellen Umgebungen muss das Zertifikatslebenszyklusmanagement zudem auf den Lebenszyklus der Maschinen und Geräte abgestimmt sein, die durch die Zertifikate geschützt werden. Ein Zertifikat, das auf einer SPS mit einer Betriebsdauer von 15 Jahren eingesetzt wird, erfordert einen grundlegend anderen Verwaltungsansatz als ein Zertifikat auf einem Webserver, das monatlich neu bereitgestellt wird.

Häufige Anwendungsfälle für X.509-Zertifikate

X.509-Zertifikate sichern die Kommunikation in einer Vielzahl von Umgebungen, von Websites für Endverbraucher bis hin zu Fertigungsstätten.

Anwendungsfälle im IT-Bereich

• Websicherheit (HTTPS):Der offensichtlichste Anwendungsfall. Jede Website, die Inhalte über HTTPS bereitstellt, verwendet ein X.509-Zertifikat zur Serverauthentifizierung und Verschlüsselung.
• E-Mail-Verschlüsselung (S/MIME):X.509-Zertifikate verschlüsseln E-Mail-Nachrichten und überprüfen die Identität des Absenders, wodurch vertrauliche Kommunikation vor dem Abfangen und vor Identitätsbetrug geschützt wird.
• Code-Signierung:Software signieren ausführbare Dateien, Updates und Skripte mit X.509-Zertifikaten, sodass Benutzer und Systeme überprüfen können, ob der Code seit der Signierung verändert wurde.
• VPN-Authentifizierung:X.509-Zertifikate dienen der Authentifizierung von VPN-Endpunkten und ersetzen oder ergänzen die passwortbasierte Authentifizierung durch eine zertifikatsbasierte Identitätsprüfung.
• Gegenseitiges TLS API-Sicherheit:In Microservices-Architekturen und API-Gateways kommt zunehmend gegenseitiges TLS X.509-Zertifikaten zum Einsatz, um sowohl Client als auch Server zu authentifizieren und Zero-Trust-Sicherheitsmodelle zu unterstützen.

Anwendungsfälle IoT OT und IoT

Industrielle Umgebungen stellen das Zertifikatsmanagement vor besondere Herausforderungen, darunter längere Lebenszyklen der Geräte, begrenzte Rechenressourcen und Protokolle der Betriebstechnik (OT), die sich erheblich von IT-Standards unterscheiden.

• SPS (speicherprogrammierbare Steuerungen):Industriesteuerungen verwenden X.509-Zertifikate zur Authentifizierung der Kommunikation mit übergeordneten Systemen, um zu verhindern, dass unbefugte Befehle die Produktionsanlagen erreichen.
• HMIs (Mensch-Maschine-Schnittstellen):Bedienfelder und Visualisierungssysteme nutzen Zertifikate, um ihre Verbindungen zu den zugrunde liegenden Steuerungssystemen zu sichern.
• Edge- und Remote-Gateways:Geräte, die OT-Netzwerke mit Cloud-Plattformen oder IT-Systemen verbinden, sind auf Zertifikate angewiesen, um eine authentifizierte, verschlüsselte Datenübertragung zu gewährleisten.
• OPC UA (Open Platform Communications Unified Architecture):Der führende Standard für die industrielle Kommunikation nutzt X.509-Zertifikate als primären Mechanismus für die Authentifizierung und Verschlüsselung zwischen industriellen Komponenten.
• Industrielle Firewalls und Sicherheitsgeräte:Netzwerksicherheitsgeräte in OT-Umgebungen nutzen Zertifikate, um vertrauenswürdige Kommunikationskanäle einzurichten und Zugriffsrichtlinien durchzusetzen.

Die Norm IEC 62443 für industrielle Cybersicherheit schreibt PKI und zertifikatsbasierte Sicherheit ab Sicherheitsstufe 2 vor und legt damit X.509-Zertifikate als Konformitätsanforderung für viele Industrieunternehmen fest.

X.509-Zertifikate und Post-Quanten-Kryptografie

Das Aufkommen des Quantencomputings stellt eine langfristige Bedrohung für die kryptografischen Algorithmen dar, auf denen die derzeitigen X.509-Zertifikate basieren. Unternehmen, die aus Sicherheitsgründen auf X.509-Zertifikate angewiesen sind, müssen sich über den Zeitplan im Klaren sein und bereits jetzt mit den Vorbereitungen beginnen.

Nicht signierte Vertrauensanker

Eine der unmittelbarsten Änderungen am X.509-Standard ist die Einführung von nicht signierten Vertrauensankern. Mit einem bevorstehenden Update des RFC 5280 entfällt die Anforderung, dass selbstsignierte Stammzertifikate eine Signatur enthalten müssen.

Die Begründung ist einfach: Da Root-CA-Zertifikate selbstsigniert sind, haben ihre Signaturen keinen praktischen Nutzen. Niemand überprüft tatsächlich die Selbstsignatur anhand eines Vertrauensankers. Tools wie OpenSSL und Bouncy Castle die Signaturen von Root-Zertifikaten in der Praxis noch nie überprüft.

Mit Post-Quanten-Algorithmen werden Signaturen deutlich umfangreicher. Algorithmen wie ML-DSA-87 und SLH-DSA erzeugen Signaturen, die erheblich mehr Speicherplatz beanspruchen als ihre klassischen Pendants. Das Entfernen unnötiger Signaturen aus Vertrauensankern spart nennenswerten Speicherplatz, insbesondere in Umgebungen mit begrenzten Ressourcen.

Bouncy Castle unterstützt Bouncy Castle nicht signierte Vertrauensanker, und es wird erwartet, dass der RFC diesen Ansatz formalisieren wird, während der Standard auf die Post-Quanten-Fähigkeit hinarbeitet.

Kryptografische Flexibilität und Vorbereitung

Der Übergang zur Post-Quanten-Kryptografie erfordert von Unternehmen Folgendes:

• Erstellen Sie eine Bestandsaufnahme aller kryptografischen Ressourcen:Erfassen Sie, wo jedes X.509-Zertifikat eingesetzt wird, welche Algorithmen es verwendet und wann es abläuft.
• Kryptografische Flexibilität erreichen:Schaffen Sie die Möglichkeit, kryptografische Algorithmen auszutauschen, ohne die Systemarchitektur neu gestalten zu müssen. Das bedeutet, fest programmierte Algorithmen zu vermeiden und PKI-Plattformen einzusetzen, die algorithmische Flexibilität unterstützen.
• Entwicklung von Standards verfolgen:Das NIST hat seine erste Reihe von Post-Quanten-Algorithmen (ML-KEM, ML-DSA, SLH-DSA) fertiggestellt, und Organisationen sollten damit beginnen, die Ausstellung von PQC-kompatiblen Zertifikaten in Nicht-Produktionsumgebungen zu testen.
• Plan für Hybridzertifikate:Während der Übergangsphase müssen Organisationen möglicherweise sowohl klassische als auch postquanten-sichere Algorithmen gleichzeitig unterstützen.

Die Kombination aus kürzeren Gültigkeitsdauern von Zertifikaten und dem Übergang zur postquantenkryptografie bedeutet, dassdie Vorbereitung auf die Postquantenkryptografie bis 2030keine weit in der Zukunft liegende Planungsaufgabe ist. Es handelt sich vielmehr um einen aktiven Arbeitsschwerpunkt für jede Organisation, die digitales Vertrauen ernst nimmt.

Wie Keyfactor helfen Keyfactor

Die in diesem Leitfaden behandelten Herausforderungen (Zertifikatswucher, Einschränkungen bei der manuellen Verwaltung, Risiken selbstsignierter Zertifikate, Komplexität des Lebenszyklus und Post-Quantum-Bereitschaft) weisen auf einen gemeinsamen Bedarf hin: eine einheitliche Plattform für die Verwaltung digitaler Vertrauensbeziehungen in großem Maßstab.

Keyfactor diese Herausforderungen in vier Schlüsselbereichen Keyfactor :

• Moderne PKI-Infrastruktur (EJBCA):Keyfactor EJBCA ist eine open-source der Enterprise-Klasse, die von Unternehmen weltweit zur Ausstellung und Verwaltung von X.509-Zertifikaten in großem Maßstab genutzt wird. EJBCA Standard-Registrierungsprotokolle (SCEP, CMP, EST, ACME), flexible Bereitstellungsmodelle (lokal, in der Cloud oder hybrid) sowie die für den Übergang zu PQC erforderliche Krypto-Agilität.
• Automatisierung des Zertifikatslebenszyklus (Command):Keyfactor Command bietet durchgängige Transparenz und Automatisierung für das Zertifikatslebenszyklusmanagement – von der Erfassung und Bestandsaufnahme bis hin zur Ausstellung, Erneuerung und Sperrung. Es lässt sich in Zertifizierungsstellen (CAs) im gesamten Unternehmen integrieren, sorgt für die Durchsetzung einheitlicher Richtlinien und macht manuelle Nachverfolgung überflüssig.
• Erkennung und Bestandsaufnahme kryptografischerRessourcen:AgileSecKeyfactorerkennt automatisch alle kryptografischen Ressourcen in der gesamten Umgebung und bietet so die erforderliche Transparenz, um die Quantencomputer-Bereitschaft zu bewerten und Sicherheitsrichtlinien durchzusetzen.
• PKI as a Service:Für Unternehmen, die eine verwaltete PKI-Infrastruktur ohne betrieblichen Aufwand benötigen, Keyfactor gehostete PKI mit der Automatisierung des Zertifikatslebenszyklus in einemeinzigen Dienst.

In industriellen Umgebungen erweitert das „Trust Point“-Projekt Keyfactordie PKI-Funktionen auf die Betriebstechnik und bietet Lösungen für die Zertifikatsverwaltung, die speziell auf die besonderen Anforderungen industrieller Geräte, lange Maschinenlebenszyklen und OT-Protokolle zugeschnitten sind.