Was sind digitale Zertifikate? Ein umfassender Leitfaden zu Zertifikatstypen, Formaten und Vertrauenswürdigkeit

Jedes Mal, wenn Sie eine HTTPS-Seite laden, sich über SSH bei einem Server anmelden, eine verschlüsselte E-Mail versenden oder ein Gerät in ein Netzwerk einbinden, arbeitet im Hintergrund unbemerkt ein digitales Zertifikat. Diese Zertifikate bilden die Grundlage für sichere Kommunikation im Internet und in Unternehmensumgebungen. Sie verknüpfen eine verifizierte Identität mit einem kryptografischen Schlüssel, sodass Systeme einander vertrauen können, ohne sich jemals zuvor begegnet zu sein.

Diese bisher eher im Hintergrund stehende Aufgabe ist mittlerweile zu einem dringenden betrieblichen Problem geworden. Unternehmen verwalten heute mehr Maschinen, Dienste und Geräte als je zuvor, und die Anzahl der im Einsatz befindlichen Zertifikate ist entsprechend gestiegen. Gleichzeitig soll die maximale Gültigkeitsdauer eines öffentlich vertrauenswürdigen Zertifikats ab März 2029 auf nur noch 47 Tage sinken, was die Zeitfenster für die Erneuerung verkürzt und eine manuelle Nachverfolgung unmöglich macht.

Dieser Leitfaden erläutert, was ein Zertifikat ist, welche wichtigen Formatfamilien es gibt, wie Vertrauen durch Zertifizierungsstellen und Zertifikatsketten hergestellt wird und wie Zertifikate vor Ablauf ihrer Gültigkeit ungültig gemacht werden. Am Ende werden Sie nicht nur die technischen Abläufe verstehen, sondern auch, warum die Zertifikatsverwaltung zu einer grundlegenden Säule des digitalen Vertrauens geworden ist.

Was ist ein digitales Zertifikat?

Ein digitales Zertifikat ist eine Datei, die eine verifizierte Identität – beispielsweise einen Domainnamen, eine Organisation, eine Person oder ein Gerät – mit einem kryptografischen Schlüsselpaar verknüpft. Diese Verknüpfung ermöglicht es zwei Systemen, sich gegenseitig zu authentifizieren und Daten während der Übertragung zu verschlüsseln, selbst wenn sie zuvor noch nie miteinander interagiert haben.

Man kann sich das beispielsweise wie einen digitalen Reisepass vorstellen. Ein Reisepass enthält Informationen über seinen Inhaber und wird von einer vertrauenswürdigen Stelle ausgestellt, die für diese Informationen bürgt. Ein Zertifikat erfüllt dieselbe Funktion für eine Maschine oder einen Nutzer: Es enthält Identitätsdaten sowie einen öffentlichen Schlüssel und ist von einer Stelle signiert, der andere Systeme bereits vertrauen.

Das Herzstück jedes Zertifikats ist ein Schlüsselpaar. Der öffentliche Schlüssel ist im Zertifikat eingebettet und wird öffentlich zugänglich gemacht, während der dazugehörige private Schlüssel sicher unter der Kontrolle der Stelle verbleibt, die das Zertifikat repräsentiert. Diese asymmetrische Schlüsselpaarung ermöglicht die Identitätsprüfung.

So funktioniert ein digitales Zertifikat

In der Praxis folgt ein Zertifikat einem einfachen Ablauf. Es enthält einen öffentlichen Schlüssel und Identitätsdaten. Eine vertrauenswürdige Zertifizierungsstelle signiert es, um zu bestätigen, dass die Identität echt ist. Eine vertrauende Partei, wie beispielsweise ein Browser oder eine Anwendung, überprüft diese Signatur, bevor sie der Verbindung vertraut.

Das bekannteste Beispiel ist der „ TLS “-Handshake, der den Webdatenverkehr sichert. Im Großen und Ganzen läuft das folgendermaßen ab:

1. „Client Hello“:Der Client eröffnet die Verbindung und sendet dabei die von ihm unterstützte „ TLS “-Version und die Verschlüsselungssuiten sowie einen Zufallswert, der als „Nonce“ bezeichnet wird.
2. Zertifikatsvorlage:Der Server antwortet mit seinem signierten Zertifikat und einer Signatur über den Nonce und weist damit seine verifizierte Identität nach.
3. Validierung:Der Client überprüft die Nonce-Signatur mit dem öffentlichen Schlüssel im Zertifikat und verfolgt anschließend die Signatur des Zertifikats selbst entlang der Kette bis zu einer vertrauenswürdigen Stammzertifizierungsstelle zurück. Dadurch wird bestätigt, dass der Server tatsächlich der ist, für den er sich ausgibt.
4. Schlüsselaustausch:Sobald die Identität bestätigt ist, vereinbaren beide Seiten einen gemeinsamen symmetrischen Schlüssel.
5. Sicherer Kanal:Dieser symmetrische Schlüssel verschlüsselt den weiteren Verlauf der Sitzung und schützt die Daten so vor Abfangen oder Manipulation.

Die Signatur ist das, was das gesamte Modell erst funktionieren lässt. Da jeder eine Kopie eines öffentlichen Zertifikats erhalten kann, beweist die Überprüfung, ob der Nonce korrekt signiert wurde, dass die andere Partei tatsächlich über den passenden privaten Schlüssel verfügt. Bei den meisten Webverbindungen legt nur der Server ein Zertifikat vor, doch bei der gegenseitigen Authentifizierung (Mutual TLS , mTLS) müssen sich beide Seiten authentifizieren – ein Muster, das in der API-Sicherheit, bei Zero-Trust-Architekturen und in industriellen Systemen zunehmend verbreitet ist.

Ein weiteres bekanntes Beispiel ist SSH, das die Fernverwaltung absichert. Diese allgemeine Beschreibung des Protokolls lautet wie folgt.

1. „Client Hello“:Der Client eröffnet die Verbindung und tauscht dabei Informationen zur Protokollversion sowie eine Liste der unterstützten Algorithmen für den Schlüsselaustausch, den Hostschlüssel, die Verschlüsselung und die MAC-Prüfsumme aus.
2. Schlüsselaustausch:Beide Seiten generieren kurzlebige Schlüsselpaare und tauschen die öffentlichen Werte aus, woraus sich ein gemeinsames Geheimnis ergibt, das keine der beiden Seiten übermittelt. Alle bisher genannten Informationen werden in einem einzigen Austausch-Hash zusammengefasst.
3. Host-Authentifizierung:Der Server legt entweder sein Zertifikat oder seinen reinen öffentlichen Schlüssel vor, zusammen mit einer Signatur über den Austausch-Hash, wodurch er die Kontrolle über den dazugehörigen privaten Host-Schlüssel nachweist und die Identität an diesen spezifischen Austausch bindet.
4. Validierung:Der Client überprüft die Signatur und prüft anschließend, ob er dem Hostschlüssel selbst vertraut – entweder, weil der Schlüssel bereits in seiner Liste bekannter Hosts enthalten ist, oder weil der Schlüssel in einem Zertifikat enthalten ist, das von einer vom Client als vertrauenswürdig eingestuften Zertifizierungsstelle signiert wurde. Ab diesem Zeitpunkt ist die Verbindung verschlüsselt.
5. Benutzerauthentifizierung:Innerhalb des nun verschlüsselten Kanals weist der Client die Identität des Benutzers nach, meist durch Signieren einer Challenge mit einem privaten Schlüssel, dessen öffentliche Hälfte der Server bereits akzeptiert.

Es ist erwähnenswert, dass Zertifikate bei SSH optional sind. Das Modell ohne Zertifikate funktioniert gut im kleinen Maßstab, wo jeder Client eine Liste bekannter Hosts und jeder Server eine Liste autorisierter Schlüssel verwaltet. Mit wachsender Netzwerkgröße stößt dieses Modell jedoch aus zwei Gründen an seine Grenzen. Erstens wächst die Anzahl der zu verteilenden Vertrauensbeziehungen mit dem Produkt aus Benutzern und Hosts, während eine Zertifizierungsstelle diese auf einen einzigen vertrauenswürdigen Schlüssel auf jeder Seite reduziert. Zweitens haben Einträge in diesen Dateien kein Ablaufdatum, sodass der Zugriff so lange bestehen bleibt, bis jemand sie manuell entfernt, während Zertifikate von selbst ablaufen. Es gibt zudem eine Lücke, die das dateibasierte Modell nicht schließen kann: Bei einer ersten Verbindung zu einem unbekannten Host hat der Client nichts, woran er die Verbindung überprüfen kann, und greift daher darauf zurück, den Nutzer zu bitten, einen Fingerabdruck zu akzeptieren, den dieser selten überprüft.

Wie viele Arten von digitalen Zertifikaten gibt es?

Es gibt drei Haupttypen von digitalen Zertifikaten:

• Serverzertifikatesichern Daten während der Übertragung über das offene Internet und bestätigen, dass eine Website tatsächlich die ist, für die sie sich ausgibt. Sie stellen den öffentlichen Schlüssel bereit, der die Sicherheit des Protokolls gewährleistet, und tragen dazu bei, Domain-Spoofing und Man-in-the-Middle-Angriffe zu verhindern.
• Code-Signatur-Zertifikateweisen nach, wer eine Softwarekomponente ( software ) veröffentlicht hat, und bestätigen, dass der Code seit seiner Signierung nicht verändert wurde. Ein bei der Signierung angefügter Zeitstempel sorgt dafür, dass die Signatur auch nach Ablauf des Zertifikats selbst gültig bleibt, was für langlebige Softwarekomponenten ( software) von Bedeutung ist.
• Benutzer- bzw. Client-Zertifikatedienen der Authentifizierung von Personen oder Geräten. Sie stellen eine weitaus sicherere Alternative zu Passwörtern dar und eignen sich ideal für die Zwei-Faktor-Authentifizierung sowie für Zero-Trust-Zugriffskonzepte.

Die drei unterscheiden sich zwar in ihrem Zweck, haben aber eine gemeinsame Eigenschaft: Vertrauen. Jede basiert auf einer verifizierten Identität und einem Schlüsselpaar, das eine vertrauende Partei überprüfen kann.

Zertifikatsformatfamilien

Es gibt kein einheitliches Zertifikatsformat, das für alle Anwendungen geeignet ist. Verschiedene Protokolle erfordern unterschiedliche Formate, die jeweils auf die Anforderungen des jeweiligen Systems zugeschnitten sind. Der X.509-Standard weist beispielsweise darauf hin, dass SSH bewusst einen anderen Zertifikatstyp verwendet, da das SSH-Protokoll eigene Anforderungen hat, und dass PGP auf einem dezentralen Modell statt auf zentralen Zertifizierungsstellen basiert.

Vier Familien decken den Großteil dessen ab, was Ihnen in der Praxis begegnen wird: X.509, SSH, OpenPGP und die JSON-basierten JOSE-Formate. In den folgenden Abschnitten werden diese nacheinander erläutert, bevor sie nebeneinander verglichen werden.

X.509-Zertifikate

X.509 bildet die Grundlage der Public-Key-Infrastruktur (PKI). Es basiert auf dem Verzeichnisstandard X.500, wurde von der Internationalen Fernmeldeunion eingeführt und in RFC 5280 als Internetstandard festgelegt. Es verknüpft eine verifizierte Identität mit einem Schlüsselpaar und definiert die genauen Felder, die ein Zertifikat systemübergreifend kompatibel machen. Hier geben wir einen kurzen Überblick über dieses Format. Weitere Informationen finden Sie in unseremumfassenden Leitfaden zu X.509-Zertifikaten.

Kernfelder.
Jedes X.509-Zertifikat enthält einen festgelegten Datensatz, darunter eine Versionsnummer, eine von der ausstellenden Zertifizierungsstelle zugewiesene Seriennummer, eine Kennung des Signaturalgorithmus, den Namen des Ausstellers, eine Gültigkeitsdauer sowie Informationen zum öffentlichen Schlüssel des Zertifikatsinhabers. Die Gültigkeitsdauer wird durch zwei Zeitstempel festgelegt – „nicht vor“ und „nicht nach“ –, die begrenzen, wie lange das Zertifikat als vertrauenswürdig gilt, und den Schaden mindern, den ein offengelegter privater Schlüssel verursachen kann.

Erweiterungen der Version 3.
Mit Version 3wurde ein Erweiterungsframework eingeführt, das die Ausdrucksmöglichkeiten eines Zertifikats erheblich erweitert hat. Jede Erweiterung verfügt über eine Kennung, ein „Critical“-Flag und einen Wert. Erkennt ein Empfänger eine als „Critical“ gekennzeichnete Erweiterung nicht, muss er das Zertifikat ablehnen. Zu den gängigen Erweiterungen zählen Einschränkungen der Schlüsselverwendung, alternative Namen des Zertifikatsinhabers (wodurch ein Zertifikat mehrere Domänen abdecken kann), Zertifikatsrichtlinien sowie grundlegende Einschränkungen, die Zertifikate von Zertifizierungsstellen (CA) von Zertifikaten für Endentitäten unterscheiden.

Versionshistorie.
In Version1 (1988) wurde die Kernstruktur definiert. In Version 2 (1993) wurden eindeutige Identifikatoren für Aussteller und Subjekt hinzugefügt, die heute als veraltet gelten. In Version 3 (ab 1996) wurde das Erweiterungs-Framework eingeführt, und praktisch alle Zertifikate, die heute im Einsatz sind, entsprechen Version 3.

Kodierung: DER vs. PEM.
Der Standard legt fest, was ein Zertifikat enthält, jedoch nicht, wie es zur Speicherung oder Übertragung kodiert werden soll. Zwei Formate dominieren. DER (Distinguished Encoding Rules) ist ein kompaktes Binärformat, das von Browsern, Betriebssystemen und Java-Anwendungen effizient verarbeitet wird und üblicherweise die Dateiendungen .der oder .cer verwendet. PEM (Privacy Enhanced Mail) wandelt diese Binärdaten in Base64-Text um, der an seinem „BEGIN CERTIFICATE“-Header zu erkennen ist, und ist die gängige Wahl auf Linux-Systemen, Webservern und in command-Line-Tools wie OpenSSL. Beide enthalten identische Daten; der einzige Unterschied besteht in der Darstellung, und die Konvertierung zwischen den beiden Formaten ist unkompliziert.

Anwendungsfälle.
X.509-Zertifikate sorgen für Web-Sicherheit über HTTPS, E-Mail-Sicherheit über S/MIME, Codesignierung, Geräteauthentifizierung, VPN-Authentifizierung und gegenseitige Authentifizierung ( TLS ) für APIs. Sie sichern zudem die Betriebstechnik, wo Standards wie OPC UA auf sie zurückgreifen und die Norm IEC 62443 ab einem bestimmten Sicherheitsniveau zertifikatsbasierte Sicherheit vorschreibt.

SSH-Zertifikate

Bei der reinen SSH-Schlüsselauthentifizierung müssen sowohl Client als auch Server vertrauenswürdige Schlüssellisten speichern und manuell verwalten, was nur schwer skalierbar ist und beim Schlüsselaustausch die Gefahr der Identitätsfälschung birgt. SSH-Zertifikate lösen dieses Problem, indem sie eine Identität an einen Schlüssel binden und den Vertrauenspunkt auf eine einzige Zertifizierungsstelle (CA) reduzieren, die sowohl Clients als auch Server authentifizieren kann.

SSH definiert zwei Zertifikatstypen:Benutzerzertifikatefür Clients undHost-Zertifikatefür Server. Anstelle der von X.509 verwendeten Distinguished Names stützen sich SSH-Zertifikate auf„Principals“, die ein Zertifikat an bestimmte Identitäten binden – Benutzernamen für Clients und Hostnamen für Server. Zertifikate können zudem wichtige Optionen enthalten, die ihre Verwendungsmöglichkeiten einschränken, darunter:

• force-command, wodurch das Zertifikat unabhängig von der Eingabe des Benutzers auf eine einzige command festgelegt wird.
• Quelladresse: Eine Liste von Adressen, von denen aus das Zertifikat verwendet werden darf.
• „verify-required“ – hierfür ist eine FIDO-Benutzerauthentifizierung erforderlich, beispielsweise eine PIN oder biometrische Daten für bestimmte Arten von Sicherheitsschlüsseln.

SSH unterstützt RSA in beliebiger Größe, die elliptischen Kurventypen EC P256, P384 und P521 sowie ed25519. Bemerkenswert ist, dass der Signaturalgorithmus nicht separat ausgewählt wird; in SSH wird er durch den Schlüsseltyp definiert. Und da SSH keine CA-Hierarchie definiert, sind SSH-Zertifizierungsstellen in der Regel selbstsigniert und stützen sich ausschließlich auf den öffentlichen Schlüssel.

OpenPGP-Zertifikate

OpenPGP-Zertifikate verfolgen einen grundlegend anderen Ansatz in Bezug auf Vertrauen. Anstatt jede Entscheidung über eine zentrale Stelle laufen zu lassen, nutzt OpenPGP ein dezentrales „Vertrauensnetz“, in dem jeder Nutzer die Identität eines anderen Nutzers bestätigen kann, indem er dessen Schlüssel signiert. Vertrauen entsteht durch die Bestätigungen vieler Gleichrangiger und nicht durch eine einzige Stamminstanz.

Dieses Modell spiegelt die Ursprünge von OpenPGP im Bereich der sicheren E-Mail- und Dateisignatur zwischen Einzelpersonen und Gemeinschaften wider, in denen es keine gemeinsame zentrale Autorität gibt und auch keine gewünscht wird. Seine Stärke liegt in der Autonomie: Kein „Gatekeeper“ entscheidet, wer teilnehmen darf. Seine Schwäche liegt in der Skalierbarkeit und Konsistenz, da das Vertrauen davon abhängt, wie gut ein bestimmter Schlüssel innerhalb des Netzwerks vernetzt ist und wie sorgfältig sich die Teilnehmer vor dem Signieren gegenseitig überprüfen. Aus diesem Grund funktioniert das Vertrauensnetzwerk in der Regel am besten innerhalb eng verbundener Gemeinschaften und weniger im offenen Internet, wo sich das hierarchische Modell durchgesetzt hat.

JOSE-Formate (JWT, JWS, JWK)

Die JOSE-Familie – kurz für „JSON Object Signing and Encryption“ – gewährleistet Identität und Integrität in JSON-basierten Systemen und nicht in den binären Strukturen, auf denen X.509 beruht. Es lohnt sich, dies als Vergleichspunkt zu verstehen, da es in der modernen Web- und API-Entwicklung ständig auftaucht, obwohl es sich nicht um ein Zertifikatsformat im herkömmlichen Sinne handelt.

• JWT (JSON Web Token)ist ein kompaktes, URL-sicheres Token, das Angaben zu einem Subjekt enthält und vor allem als „Bearer-Token“ bekannt ist, das bei der Web-Authentifizierung und beim Single Sign-On weitergegeben wird.
• JWS (JSON Web Signature)legt fest, wie dieser JSON-Inhalt signiert werden muss, damit ein Empfänger überprüfen kann, ob er nicht manipuliert wurde.
• JWK (JSON Web Key)stellt einen kryptografischen Schlüssel als JSON-Objekt dar, was die Schlüsselverteilung für Dienste vereinfacht, die bereits JSON unterstützen.

Während X.509 eine Identität und einen öffentlichen Schlüssel in ein signiertes Zertifikat bündelt, das über eine CA-Kette validiert wird, dienen JOSE-Formate in der Regel dazu, signierte Angaben und Schlüssel zwischen Diensten auszutauschen, die bereits eine Vertrauensbeziehung unterhalten, wie beispielsweise ein Identitätsanbieter und die darauf zugreifenden Anwendungen. Oftmals kommen beide Formate nebeneinander zum Einsatz: Ein API-Gateway könnte eine „ TLS “-Verbindung mit einem X.509-Zertifikat herstellen und die Anfrage anschließend mithilfe eines JWT autorisieren.

Die Formatfamilien auf einen Blick im Vergleich

Format	Vertrauensmodell	Typische Anwendung	Kodierung
X.509	Hierarchische Zertifizierungsstellen	TLS, S/MIME, Code-Signierung, Geräte- und mTLS-Authentifizierung	DER (Binär) oder PEM (Base64-Text)
SSH	Eine einzelne, in der Regel selbstsignierte SSH-Zertifizierungsstelle	Client- und Server-Authentifizierung für den Fernzugriff	SSH-Zertifikatsformat, verschlüsselt mit RSA, EC oder ed25519
OpenPGP	Dezentrales Vertrauensnetzwerk	Signieren und Verschlüsseln von E-Mails und Dateien	OpenPGP-Nachrichten- und Schlüsselformat
JOSE (JWT/JWS/JWK)	Gemeinsames Vertrauen zwischen Diensten	Web- und API-Token, Claims und Schlüsselaustausch	JSON-Text

Die deutlichste Trennlinie ist das Vertrauensmodell. X.509 und SSH stützen sich auf benannte Zertifizierungsstellen, OpenPGP verteilt das Vertrauen auf die Peers, und JOSE geht davon aus, dass zwischen den Diensten, die Token austauschen, bereits eine Vertrauensbeziehung besteht.

Das Vertrauensmodell: Wie Zertifikate Vertrauen schaffen

Hinter jedem Format verbirgt sich eine Vertrauensfrage: Warum sollte eine vertrauende Partei einem Zertifikat überhaupt Glauben schenken? Zwei Modelle geben darauf eine Antwort.

Imhierarchischen Modellstehen die Zertifizierungsstellen an oberster Stelle. Eine kleine Anzahl allgemein anerkannter Stammzertifikate bildet das Fundament des Systems, und alle anderen Zertifikate leiten ihre Vertrauenswürdigkeit von diesen ab. Dasdezentrale Vertrauensnetzwerk, das von OpenPGP genutzt wird, verteilt das Vertrauen auf gleichberechtigte Teilnehmer, die sich gegenseitig ohne zentralen Anker bestätigen.

Beide Ansätze sind gültig, skalieren jedoch unterschiedlich. Das hierarchische Modell bildet die Grundlage für den Einsatz in Unternehmen und im Internet, da zentralisierte Vertrauensentscheidungen und automatisierte Validierung genau das sind, was große, schnelllebige Umgebungen benötigen. Das Vertrauensnetzwerk hingegen kommt in kleineren Gemeinschaften gut zur Geltung, in denen sich die Teilnehmer gegenseitig persönlich überprüfen können.

Zertifikatsketten und Zertifizierungsstellen

Die hierarchische Vertrauensstellung funktioniert über eine Kette, die ein Client vom ihm vorliegenden Zertifikat bis hin zu einer Stammzertifizierungsstelle zurückverfolgen kann, der er bereits vertraut. Eine typische Kette umfasst drei Ebenen:

1. Einselbstsigniertes Root-CA-Zertifikat, das in den Vertrauensspeichern des Browsers und des Betriebssystems vorinstalliert ist und dessen privater Schlüssel sicher offline aufbewahrt wird.
2. EinZwischenzertifikat einer Zertifizierungsstelle, das die alltäglichen Aufgaben der Zertifikatssignierung übernimmt, damit der Schlüssel der Stammzertifizierungsstelle geschützt bleibt.
3. DasEndentitätszertifikat, das von einer Website, einem Server oder einem Gerät vorgelegt wird.

Wenn ein Client ein Endentitätszertifikat erhält, überprüft er jede Signatur entlang der Kette und akzeptiert das Zertifikat nur, wenn alle Glieder der Kette gültig sind und es eine vertrauenswürdige Stammzertifizierungsstelle erreicht. Die Vertrauensspeicher variieren je nach Client. Firefox unterhält laut der„Mozilla Included CA Certificate List“ einen eigenen Speicher mit rund 120 vertrauenswürdigen Stammzertifikaten für TLS, während Chrome sich in der Regel auf den Speicher des Betriebssystems stützt – mit Ausnahmen wie einer separaten Liste für „Extended Validation“ und den Anforderungen an die Zertifikatstransparenz. Das Vertrauen kann durch gegenseitige Zertifizierung sogar organisationsübergreifend sein: Dabei signieren zwei Stammzertifikate gegenseitig ihre Zertifikate, sodass Clients, die dem einen vertrauen, auch die unter dem anderen ausgestellten Zertifikate akzeptieren.

Validierungsstufen

Jedes Zertifikatssystem, unabhängig von seinem Format, muss vor der Ausstellung eines Zertifikats dieselbe Frage beantworten: Wie sicher können wir sein, dass der Zertifikatsinhaber tatsächlich der ist, für den er sich ausgibt? Die Antwort ist niemals eindeutig, daher entwickelt jede Systemfamilie eine Methode, um diese Sicherheit einzustufen und diese Einstufung an diejenigen weiterzugeben, die sich später auf das Zertifikat verlassen werden. Bei „ TLS “ handelt es sich um die bekannte Abstufung aus „Domain Validation“, die lediglich die Kontrolle über einen Namen nachweist; „Organization Validation“, die zusätzlich überprüft, ob eine juristische Person existiert und mit diesem Namen verbunden ist; sowie „Extended Validation“, die Eintragungen im Handelsregister, eine physische Präsenz und die Bestätigung der Signaturberechtigung einbezieht. Die Codesignierung nutzt dieselbe abgestufte Logik, wobei die unterste Stufe abgeschafft wurde, sodass die Identität des Herausgebers nun stets auf Organisationsebene verifiziert wird, wobei die Schlüssel unter hardware verwahrt werden. Client- und S/MIME-Zertifikate folgen demselben Muster, von der Kontrolle des E-Mail-Postfachs bis hin zur verifizierten individuellen Identität, die durch behördliche Dokumente untermauert wird. In jedem Fall wird die Stufe als Policy-OID im Zertifikat vermerkt, sodass eine vertrauende Partei das Sicherheitsniveau ablesen kann, anstatt es ableiten zu müssen.

Derselbe Instinkt zeigt sich überall dort, wo Zertifikate verwendet werden – selbst in Systemen, die dem Modell einer öffentlichen Zertifizierungsstelle (CA) in keiner Weise ähneln. PGP erfasst dies als Vertrauenswert, den der Unterzeichner jeder Signatur beifügt, sodass die vertrauende Partei mehrere Bescheinigungen gegeneinander abwägen kann, anstatt sich auf eine einzige zu verlassen. SSH erfasst dies implizit im Bereitstellungsprozess hinter der Zertifizierungsstelle: Ein Zertifikat, das erst ausgestellt wird, nachdem der Host in das Konfigurationsmanagement aufgenommen wurde oder nachdem sich der Benutzer bei einem Identitätsanbieter authentifiziert hat, bietet genau so viel Sicherheit, wie diese vorgelagerten Prüfungen gewährleisten – weshalb SSH-Zertifizierungsstellen Zertifikate sicher innerhalb von Stunden ausstellen können. Was sich zwischen den Familien unterscheidet, ist, wo der Sicherheitsgrad festgehalten wird und wem die Zuweisung anvertraut wird. Gemeinsam ist ihnen die Erkenntnis, dass ein Zertifikat immer nur so stark ist wie die Identitätsprüfung, die vor seiner Signierung durchgeführt wurde, und dass die Stärke dieser Prüfung mit dem Zertifikat mitgeliefert werden muss, anstatt dass die vertrauende Partei sie erraten muss.

Selbstsignierte Zertifikate im Vergleich zu von einer Zertifizierungsstelle ausgestellten Zertifikaten

Ein selbstsigniertes Zertifikat wird von derselben Stelle signiert, die es erstellt hat. Es ermöglicht zwar eine Authentifizierung, bietet jedoch keine unabhängige Identitätsprüfung. Die Analogie zum Reisepass trifft es auf den Punkt: Wenn man seinen eigenen Namen auf ein Blatt Papier schreibt und dieses an einer Grenze vorzeigt, erhält man ein schönes Dokument, hinter dem jedoch keine nachgewiesene Identität steht. Fachleute bezeichnen selbstsignierte Zertifikate sowohl als unverwaltet als auch als unüberprüft, da niemand das Ablaufdatum im Auge behält, das der Ersteller stillschweigend festgelegt hat. Wenn diese Zertifikate ablaufen, kommt es häufig zu Ausfällen, und Probleme mit selbstsignierten Zertifikaten sind eine häufige Ursache dafür.

Aus diesem Grund sind selbstsignierte Zertifikate nur in kontrollierten, nicht produktiven Umgebungen geeignet, wie beispielsweise bei der lokalen Entwicklung, in isolierten internen Labors und bei Proof-of-Concept-Demonstrationen. Für den Produktiveinsatz sind von einer Zertifizierungsstelle (CA) ausgestellte Zertifikate erforderlich, da sie eine überprüfbare Vertrauenskette bieten, die von Browsern und Anwendungen automatisch validiert wird – gestützt durch eine Zertifizierungsstelle, die die Identität des Inhabers überprüft hat, sowie einen verwalteten Lebenszyklus, der das Ablaufdatum nachverfolgt. Eine erwähnenswerte Nuance: Root-CA-Zertifikate sind selbst selbstsigniert, doch dies ist eine strukturelle Eigenschaft eines Vertrauensankers, wobei das Vertrauen durch die Verteilung in Vertrauensspeicher und nicht durch die Signatur selbst begründet wird.

Zertifikatssperrung

Zertifikate sind von Natur aus befristet, doch die bloße Ablaufdauer reicht nicht aus. Manchmal muss ein Zertifikat bereits weit vor seinem Ablaufdatum für ungültig erklärt werden, beispielsweise wenn ein privater Schlüssel kompromittiert wurde, ein System außer Betrieb genommen wird oder ein Zertifikat schlichtweg nicht mehr benötigt wird. Sobald bekannt wird, dass ein privater Schlüssel kompromittiert wurde, ist das Zertifikat ungültig, unabhängig davon, wie lange seine Gültigkeitsdauer noch beträgt.

Es ist hilfreich, zwei Konzepte voneinander zu unterscheiden.Die Gültigkeitsdauerist der passive Gültigkeitszeitraum, der in jedes Zertifikat integriert ist.Die Sperrungist der aktive Schritt, bei dem das Vertrauen vor Ablauf dieses Zeitraums entzogen wird. Die Sperrung ist ein zentraler Schritt im Zertifikatslebenszyklusmanagement und die Kontrollmaßnahme, die die Vertrauenskette aufrechterhält, wenn sich die realen Bedingungen schneller ändern, als es die Gültigkeitsdauer zulässt.

So funktioniert die Überprüfung auf widerrufene Zertifikate (CRL und OCSP)

Vertrauende Parteien benötigen eine Möglichkeit, um zu erfahren, dass ein Zertifikat widerrufen wurde. Dabei gibt es vor allem zwei Mechanismen.

EineZertifikatssperrliste (CRL)ist eine von einer Zertifizierungsstelle veröffentlichte, signierte und mit einem Zeitstempel versehene Datei, die die Seriennummern von Zertifikaten auflistet, die vor Ablauf ihrer Gültigkeit gesperrt wurden. Gemäß der Definition in RFC 5280 enthält jeder Eintrag die Seriennummer, das Sperrdatum und optional einen Grundcode, beispielsweise „Schlüsselkompromittierung“ oder „Einstellung des Betriebs“. Eine vertrauende Partei findet die Liste über die CRL-Verteilungspunkte-Erweiterung im Zertifikat, lädt sie herunter und prüft, ob die Seriennummer darin enthalten ist. CRLs sind einfach und werden universell unterstützt, können jedoch sehr groß werden. Aus diesem Grund gibt es partitionierte und Delta-CRLs, um die Downloads überschaubar zu halten. In diesem Leitfaden erfahren Sie mehr darüber,was eine Zertifikatssperrliste ist.

Das in RFC 6960 definierteOnline Certificate Status Protocol (OCSP) kehrt dieses Modell um. Anstatt eine vollständige Liste herunterzuladen, fragt der Client nach einem einzelnen Zertifikat, indem er den OCSP-Responder abfragt, der in der Erweiterung „Authority Information Access“ des Zertifikats angegeben ist. Der Responder gibt eine kurze, signierte Antwort zurück: „good“, „revoked“ oder „unknown“. OCSP-Stapling verbessert dies noch weiter, indem es dem Webserver ermöglicht, die Antwort abzurufen und zwischenzuspeichern, um sie dann während des „ TLS “-Handshakes zu übermitteln, was die Latenzzeit verkürzt und die Privatsphäre der Nutzer schützt. Die technischen Detailszur Funktionsweise von OCSP finden Sie in dieser Erklärung.

Bei beiden Ansätzen geht es um einen Kompromiss zwischen Aktualität und Effizienz, und viele Teams setzen beide ein. Wenn Sie abwägen, auf welchen Ansatz Sie sich konzentrieren sollen, hilft Ihnen dieser Vergleich zwischenCRL und OCSPbei der Entscheidung. Bemerkenswert ist: Im öffentlichen Web gehen Browser zunehmend zu lokal verteilten Sperrdaten über, während OCSP und CRLs für Unternehmens- und private PKI-Systeme weiterhin eine zentrale Rolle spielen.

Widerruf über alle Formate hinweg

Die Sperrung ist nicht bei allen Zertifikatstypen identisch. SSH verwendet beispielsweise Key Revocation Lists (KRLs) anstelle von CRLs im X.509-Format und stützt sich stark auf kurzlebige, manchmal sogar kurzfristige Zertifikate. Wenn ein Zertifikat nur wenige Stunden gültig ist, verkürzt sich das Zeitfenster, in dem der Widerruf von Bedeutung ist, drastisch, was die Abhängigkeit von der Widerrufsprüfung von vornherein verringert. Dieses Muster, bei dem kurze Gültigkeitsdauern gegenüber einer aktiven Ungültigkeitserklärung bevorzugt werden, gewinnt in der gesamten Zertifikatswelt zunehmend an Einfluss, da sich die öffentlichen Gültigkeitsdauern auf 47 Tage verkürzen.

Wie Keyfactor helfen Keyfactor

Die Verwaltung eines einzelnen Zertifikats ist einfach. Die Verwaltung aller Zertifikate und Formate unternehmensweit – ohne Ausfälle oder Lücken in den Richtlinien – ist die eigentliche Herausforderung, und genau hier wird Automatisierung unverzichtbar. Da sich die Gültigkeitsdauer auf 47 Tage verkürzt, steigt der operative Aufwand für die Erneuerungen um etwa das Achtfache, und Tabellenkalkulationen sowie E-Mail-Erinnerungen reichen nicht mehr aus.

Keyfactor Das Unternehmen löst dieses Problem mit einem durchgängigen Ansatz zur Automatisierung des Zertifikatslebenszyklus für X.509 und SSH. EJBCA, die PKI-Plattform für Unternehmen, stellt Zertifikate in großem Maßstab aus und verwaltet diese, unterstützt Standard-Registrierungsprotokolle wie SCEP, CMP, EST und ACME und bietet die für den Übergang zur Post-Quanten-Ära erforderliche Krypto-Agilität. Keyfactor Command Die Lösung ist über alle Zertifizierungsstellen (CAs) in der Umgebung hinweg integriert und ermöglicht von einem zentralen Ort aus die Erkennung, Bestandsaufnahme, Überwachung, Erneuerung und Sperrung von Zertifikaten sowie die Überwachung von CRL- und OCSP-Endpunkten, sodass abgelaufene Zertifikate oder nicht erreichbare Responder niemals unbemerkt bleiben. Für Teams, die die Infrastruktur lieber nicht selbst betreiben möchten, bietet „PKI as a Service“ eine verwaltete PKI- und Sperrinfrastruktur.

Der Nutzen steht in direktem Zusammenhang mit den in diesem Leitfaden behandelten Herausforderungen: weniger Ausfälle, konsequente Durchsetzung von Richtlinien, Vorbereitung auf kürzere Gültigkeitsdauer von Zertifikaten und ein Vorsprung bei der postquantenkryptografischen Verschlüsselung.