Was ist eine Zertifizierungsstelle? Ein umfassender Leitfaden zum Thema digitales Vertrauen

Jede verschlüsselte Verbindung, auf die Sie sich verlassen – vom Einloggen bei einer Bank bis hin zu einem API-Aufruf zwischen Microservices –, hängt davon ab, dass eine einzige Frage korrekt beantwortet wird: Ist die Instanz am anderen Ende wirklich die, für die sie sich ausgibt? Zertifizierungsstellen dienen dazu, diese Frage zu beantworten. Sie sind die Vertrauensanker, die eine authentifizierte, verschlüsselte Kommunikation in großem Maßstab ermöglichen.

In diesem Leitfaden wird erläutert, was eine Zertifizierungsstelle ist, wie der Ausstellungsprozess abläuft, welche Vertrauenshierarchie für die Sicherheit des Systems sorgt und wie Sie entscheiden können, welche Art von Zertifizierungsstelle den Anforderungen Ihrer Organisation entspricht.

Was ist eine Zertifizierungsstelle?

Eine Zertifizierungsstelle (CA) ist eine vertrauenswürdige Stelle, die die Identität von Benutzern, Rechnern, Organisationen, Diensten usw. überprüft und anschließend digital signierte Zertifikate ausstellt, die diese Identitäten bestätigen. Im Rahmen einer Public-Key-Infrastruktur besteht die Hauptaufgabe der Zertifizierungsstelle darin, Zertifikate auszustellen und zu widerrufen sowie die Arbeitsabläufeim Zertifikatsmanagementzu unterstützen, einschließlich der Validierung von Anträgen und der Veröffentlichung.

Im Kern verknüpft eine Zertifizierungsstelle (CA) eine Identität mit einem kryptografischen Schlüsselpaar. Wenn eine CA ein Zertifikat ausstellt, gibt sie damit eine überprüfbare Erklärung ab: „Ich habe bestätigt, dass dieser öffentliche Schlüssel zu dieser Entität gehört.“ Jeder, der der CA vertraut, kann dieser Erklärung ebenfalls vertrauen. Auf diese Weise können Fremde, die keine vorherige Beziehung zueinander haben, sichere Verbindungen herstellen.

Der Begriff „CA“ kann sich sowohl auf die Organisation beziehen, die für Identitäten bürgt, als auch auf die Serverinfrastruktur, die zur Ausstellung und Verwaltung von Zertifikaten genutzt wird. Unabhängig davon, ob sie von einem globalen Anbieter betrieben oder intern von einem IT-Team eines Unternehmens bereitgestellt wird, ist die Funktion dieselbe: eine Entität zu authentifizieren, ein signiertes Zertifikat auszustellen und dieses Zertifikat über seinen gesamten Lebenszyklus hinweg zu verwalten.

Warum Zertifizierungsstellen notwendig sind

Zertifizierungsstellen dienen dazu, ein grundlegendes Problem der Public-Key-Kryptografie effizient zu lösen: Woher weiß man, dass ein öffentlicher Schlüssel tatsächlich zu der Entität gehört, zu der er angeblich gehört?

Die Public-Key-Kryptografie ermöglicht es zwei Parteien, sicher zu kommunizieren, ohne zuvor ein Geheimnis auszutauschen, weist jedoch eine entscheidende Schwachstelle auf. Wenn Sie einen öffentlichen Schlüssel erhalten, der angeblich von Ihrer Bank stammt, gibt es am Schlüssel selbst keinen Hinweis, der diese Behauptung belegt. Ein Angreifer könnte seinen eigenen Schlüssel vorlegen, sich als die Bank ausgeben und Ihre gesamte Verbindung abfangen. Die Kryptografie garantiert die mathematische Korrektheit, nicht jedoch die Identität dahinter.

Ohne eine vertrauenswürdige dritte Partei, die Identitäten überprüft, sind Unternehmen erheblichen Risiken ausgesetzt:

• Man-in-the-Middle-Angriffe:Ein Angreifer fängt die Kommunikation zwischen zwei Parteien ab und gibt sich gegenüber der jeweils anderen Partei als diese aus.
• Identitätsbetrug:Böswillige Akteure legen gefälschte Zugangsdaten vor, die echt wirken, und verschaffen sich so unbefugten Zugriff auf Systeme und Daten.
• Datenabfang:Sensible Informationen, die über nicht verifizierte Verbindungen übertragen werden, können abgefangen und missbraucht werden.

Zertifizierungsstellen (CAs) lösen diese Probleme, indem sie als vertrauenswürdige Dritte fungieren, die für die Verknüpfung zwischen einer Identität und einem öffentlichen Schlüssel bürgen. Die Zertifizierungsstelle überprüft, ob eine Entität tatsächlich die ist, für die sie sich ausgibt, und stellt anschließend ein digital signiertes Zertifikat aus, das diese Verknüpfung bestätigt. Da die Zertifizierungsstelle mit ihrem eigenen privaten Schlüssel signiert, kann jeder die Echtheit des Zertifikats anhand des bekannten öffentlichen Schlüssels der Zertifizierungsstelle überprüfen. Sie müssen der Entität, die das Zertifikat vorlegt, nicht vertrauen; Sie müssen lediglich der Zertifizierungsstelle vertrauen, die dafür bürgt.

Dieses Modell macht Vertrauen skalierbar. Anstatt dass jede Partei einzeln Vertrauen zu jeder anderen Partei aufbauen muss (was im Internetmaßstab oder sogar innerhalb moderner Unternehmen ein unlösbares Problem darstellt), stützen sich alle auf eine relativ kleine Gruppe von Zertifizierungsstellen. Betriebssysteme und Browser werden mit einer vorinstallierten Liste vertrauenswürdiger Stammzertifizierungsstellen ausgeliefert, und diese gemeinsame Grundlage ermöglicht täglich Milliarden sicherer Verbindungen.

So funktioniert eine Zertifizierungsstelle

Der Prozess der Zertifikatsausstellung folgt einer genau festgelegten Abfolge. Das Verständnis der einzelnen Schritte verdeutlicht, wie Zertifizierungsstellen Vertrauen aufbauen und überprüfen.

Schritt 1: Schlüsselpaar generieren.
Der Antragsteller erstellt ein Paar ausöffentlichem und privatem Schlüssel. Der private Schlüssel bleibt geheim und unterliegt stets der Kontrolle des Antragstellers.

Schritt 2: Erstellen Sie eine Zertifikatssignierungsanforderung (CSR).
Der Antragsteller erstellt eine CSR, die seinen öffentlichen Schlüssel und identifizierende Informationen (wie beispielsweise einen Distinguished Name für ein X.509-Zertifikat) enthält. Die CSR wird mit dem privaten Schlüssel des Antragstellers signiert, um den Besitz nachzuweisen.

Schritt 3: Senden Sie die CSR an die Zertifizierungsstelle.
Der Antragsteller sendet die CSR zusammen mit den erforderlichen Identitätsnachweisen an die Zertifizierungsstelle. Je nach Zertifikatstyp kann die Zertifizierungsstelle rechtliche Unterlagen, einen Nachweis über die Inhaberschaft der Domain oder eine Überprüfung der Organisation verlangen.

Schritt 4: Die Zertifizierungsstelle prüft den Antrag.
Die Zertifizierungsstelle prüft die CSR, verifiziert die Identität des Antragstellers und stellt sicher, dass der Antrag ihren Ausstellungsrichtlinien entspricht.

Schritt 5: Die Zertifizierungsstelle signiert das Zertifikat und sendet es zurück.
Nach der Validierung signiert die Zertifizierungsstelle das Zertifikat mit ihrem eigenen privaten Schlüssel und sendetdas fertige Zertifikat an den Antragsteller zurück.Das Zertifikat kann nun auf Servern, Geräten oder in Anwendungen eingesetzt werden.

In IoT wird dieser Prozess für die Geräteherstellung angepasst. In einigen Fällen generiert die „Root of Trust“ des Geräts ein ECC-Schlüsselpaar und eine CSR, die an die PKI des Anbieters übermittelt werden. Der „Product Attestation Intermediate“ (PAI) signiert die Anfrage und stellt ein „Device Attestation Certificate“ (DAC) aus, das sicher auf dem Gerät gespeichert wird.

Die Rolle von öffentlichen und privaten Schlüsseln

Die asymmetrische Kryptografie bildet die Grundlage des gesamten CA-Prozesses. Jede Zertifizierungsstelle verwaltet ihr eigenes Schlüsselpaar: einen privaten Schlüssel, der zum Signieren von Zertifikaten verwendet wird, und einen öffentlichen Schlüssel, der weit verbreitet ist, sodass jeder diese Signaturen überprüfen kann.

Wenn eine Zertifizierungsstelle (CA) ein Zertifikat ausstellt, erstellt sie eine digitale Signatur, indem sie einen Hashwert des Zertifikatsinhalts mit ihrem privaten Schlüssel verschlüsselt. Jeder Empfänger kann diese Signatur anschließend mithilfe des öffentlichen Schlüssels der Zertifizierungsstelle überprüfen. Ist die Überprüfung erfolgreich, ist die Signatur gültig und das Zertifikat als vertrauenswürdig einzustufen.

Dieser Mechanismus stellt sicher, dass Zertifikate nicht gefälscht werden können. Nur die Zertifizierungsstelle, die über den privaten Schlüssel verfügt, kann eine gültige Signatur erstellen, während jeder, der den öffentlichen Schlüssel besitzt, diese überprüfen kann.

Die Vertrauenshierarchie der Zertifizierungsstellen

Das CA-Vertrauensmodell basiert auf einer mehrschichtigen Hierarchie, die Sicherheit und betriebliche Flexibilität in Einklang bringt. Die Vertrauenskette reicht von einer einzigen Stamm-CA über Zwischenzertifizierungsstellen bis hin zu den auf den Endgeräten installierten Zertifikaten.

Stammzertifizierungsstellen

Die Stamm-Zertifizierungsstelle befindet sich auf der obersten Ebene der Hierarchie und dient als Vertrauensanker. Damit ein Zertifikat einer Endentität als vertrauenswürdig gilt, muss es über eine Kette bis zu einer Stamm-Zertifizierungsstelle zurückverfolgt werden können, die in das Betriebssystem, den Browser oder das Gerät eingebettet ist, das das Zertifikat validiert.

Stamm-Zertifizierungsstellen sind streng gesichert und werden in der Regel offline betrieben. Ihre privaten Schlüssel werden in Einrichtungen nach GSA-Standards unter strengen Sicherheitsvorkehrungen aufbewahrt. Da eine Kompromittierung einer Stamm-Zertifizierungsstelle jedes Zertifikat in ihrer Hierarchie untergraben würde, stellen Stamm-Zertifizierungsstellen nur selten selbst Zertifikate aus. Stattdessen übertragen sie diese Aufgabe an untergeordnete Zertifizierungsstellen.

Zwischen-, untergeordnete und ausstellende Zertifizierungsstellen

Zwischenzertifizierungsstellen (Intermediate CAs) sind zwischen der Stammzertifizierungsstelle und den Zertifikaten der Endentitäten angesiedelt. Ihr Hauptzweck besteht darin, die Arten von Zertifikaten zu definieren und zu autorisieren, die bei der Stammzertifizierungsstelle beantragt werden können. Sie werden auch als untergeordnete Zertifizierungsstellen (Subordinate CAs) bezeichnet, da ihr eigenes Zertifikat von einer anderen Zertifizierungsstelle signiert wurde.

Unternehmen setzen in der Regel separate untergeordnete Zertifizierungsstellen für unterschiedliche Zwecke ein. In öffentlichen Hierarchien müssen beispielsweise untergeordnete Zertifizierungsstellen TLS S/MIME voneinander getrennt sein. Weitere gängige Konfigurationen sind separate untergeordnete Zertifizierungsstellen für verschiedene geografische Standorte oder eine untergeordnete Zertifizierungsstelle für Zertifikate mit ECC-Schlüsseln und eine weitere für Zertifikate mit RSA-Schlüsseln.

Eine Zwischen-Zertifizierungsstelle, die speziell für die Signierung von Zertifikaten für Endnutzer (Endentitäten) zuständig ist, wird als ausstellende Zertifizierungsstelle bezeichnet. Eine ausstellende Zertifizierungsstelle ist daher fast immer eine untergeordnete Zertifizierungsstelle, da Stammzertifizierungsstellen nur selten Zertifikate an Endnutzer ausstellen.

Zertifikate für Endentitäten

Endentitäten sind die oben erwähnten Endnutzer. Endentitätszertifikate bilden das letzte Glied in der Vertrauenskette und werden auch als „Blätter“ der PKI-Hierarchie bezeichnet. Dabei handelt es sich um Zertifikate, die auf Servern, Rechnern, kryptografischer hardware und Geräten installiert sind. Sie repräsentieren die Identität eines bestimmten Endpunkts und ermöglichen es diesem Endpunkt, authentifizierte, verschlüsselte Verbindungen herzustellen.

Jedes Endbenutzer-Zertifikat lässt sich über eine oder mehrere Zwischenzertifizierungsstellen bis zu einer vertrauenswürdigen Stammzertifizierungsstelle zurückverfolgen. Durch die Überprüfung dieser Kette stellen Systeme sicher, dass ein Zertifikat echt ist.

Arten von Zertifizierungsstellen

Öffentliche Zertifizierungsstellen

Öffentliche Zertifizierungsstellen genießen in Browsern, Betriebssystemen und Geräten standardmäßig Vertrauen. Sie stellen Zertifikate für öffentlich zugängliche Websites, Anwendungen und Dienste aus, bei denen externe Nutzer und Kunden die Identität des Servers ohne manuelle Konfiguration überprüfen müssen.

Unternehmen verlassen sich bei der Beschaffung von TLS , die die Kommunikation mit ihren Kunden sichern, auf öffentliche Zertifizierungsstellen (wie beispielsweise DigiCert). Öffentliche Zertifizierungsstellen unterliegen strengen externen Kontrollmechanismen, darunter den Baseline Requirements des CA/Browser-Forums, und ihre Zertifikate werden im Rahmen von „Certificate Transparency“ protokolliert, um die Nachvollziehbarkeit zu gewährleisten.

Private Zertifizierungsstellen

Private Zertifizierungsstellen werden intern von Organisationen betrieben, um Zertifikate für Anwendungsfälle auszustellen, die kein öffentliches Vertrauen erfordern. Zu den typischen Anwendungsbereichen privater Zertifizierungsstellen gehören:

• Sichere Kommunikation zwischen internen Diensten, einschließlich containerisierter und über APIs verbundener Cloud-Umgebungen
• Intranet-Seiten
• Zertifikat für ein virtuelles privates Netzwerk (VPN) oder drahtlose Authentifizierung
• Identifizierung des Geräts
• Workloads und Container-Identifikation
• IoT (Internet der Dinge) Projekte

Mit einer privaten Zertifizierungsstelle (CA) wird die Organisation selbst zum Vertrauensanker. Sie entscheidet, welche Identitäten gültig sind, stellt Zertifikate für ihre eigenen Dienste und Geräte aus und kontrolliert die gesamte Vertrauenshierarchie. Aus diesem Grund kann eine private Zertifizierungsstelle die Kommunikation zwischen Maschinen authentifizieren, für die keine öffentliche Zertifizierungsstelle jemals bürgen würde, und ermöglichtso Zero-Trust-Architekturenin internen Netzwerken.

Wie man sich zwischen einer öffentlichen und einer privaten Zertifizierungsstelle entscheidet

Die Entscheidung zwischen öffentlichen und privaten Zertifizierungsstellen hängt davon ab, wer dem Zertifikat vertrauen muss.

Abmessung	Öffentliche CA	Privat CA
Wer vertraut darauf?	Allgemein anerkannt durch vorinstallierte Stammzertifikatsspeicher in Browsern, Betriebssystemen und Geräten	Wird nur von Systemen als vertrauenswürdig eingestuft, die ausdrücklich so konfiguriert sind, dass sie Ihrem Root vertrauen
Hauptanwendungsfall	Benutzerorientierte Dienste: öffentliche Websites, Kunden-APIs, E-Mail-Server	Interne Infrastruktur: mTLS, Service-zu-Service-Authentifizierung, VPNs, Geräte-/Workload-Identität
Vertrauensanker	Die öffentliche Zertifizierungsstelle (externer Drittanbieter)	Ihre Organisation
Identitätsprüfung	Obligatorische Validierung von Domänen/Organisationen gemäß externen Regeln	Unabhängig davon, welches Identifikationsschema Sie definieren (interne Hostnamen, Dienstkonten, Geräte-IDs)
Geltende Vorschriften	Grundlegende Anforderungen des CA/Browser-Forums, verbindliche Standards	Ihre eigenen internen Richtlinien
Gültigkeitsdauer von Zertifikaten	Von außen vorgegeben, werden sie immer kürzer	Stellen Sie den Wert so ein, wie es zu Ihrer Umgebung passt
Öffentliche Protokollierung	Über „Certificate Transparency“ protokolliert	Es wurde nichts öffentlich protokolliert
Kostenmodell	Preise pro Zertifikat (oder kostenlose Tarife wie Let’s Encrypt)	Es fallen keine Kosten pro Zertifikat an; die Infrastruktur- und Betriebskosten tragen Sie selbst.
Skaleneffekte	Für Tausende von Zertifikaten mit kurzer Gültigkeitsdauer ist das nicht praktikabel	Entwickelt für die interne Ausgabe großer Mengen
Kontrolle	Eingeschränkt, durch die Außenpolitik bedingt	Volle Kontrolle über Richtlinien, Ausgabe und Hierarchie

Das Muster: Eine öffentliche Zertifizierungsstelle tauscht Kontrolle gegen allgemeines Vertrauen und ausgelagerte Abläufe ein, während eine private Zertifizierungsstelle den betrieblichen Aufwand gegen volle Kontrolle und Skaleneffekte innerhalb des Unternehmens eintauscht. Die meisten Organisationen betreiben beides, jeweils eine für jede Vertrauensgrenze.

Zertifizierungsstellen-Typen nach Zertifikatsformat

Abgesehen von der Unterscheidung zwischen öffentlichen und privaten Zertifizierungsstellen lassen sich diese auch nach der Art der von ihnen ausgestellten Zertifikate einteilen.

X.509-Zertifizierungsstellen

X.509 ist der gängigste Zertifizierungsstellen-Typ, der gemäß der Definition in RFC 5280 für sichere E-Mails, Anmeldungen, Web-Authentifizierung, VPN und vieles mehr verwendet wird. X.509-Zertifikate sind das Standardformat für SSL und bilden das Rückgrat der meisten PKI-Implementierungen. Sie definieren die Struktur digitaler Zertifikate, einschließlich der Distinguished Names, Gültigkeitsdauer, Erweiterungen und der für die Signierung verwendeten kryptografischen Algorithmen.

CVC-Zertifizierungsstellen

CVC-Zertifizierungsstellen stellen „Card Verifiable“ (CV)-Zertifikate aus, bei denen es sich um spezielle Zertifikate handelt, die für EU-E-Pässe mit EAC (Extended Access Control) entwickelt wurden. Diese Zertifikate ermöglichen eine sichere elektronische Identitätsprüfung für Grenzkontrollen und behördliche Identifikationssysteme.

SSH-Zertifizierungsstellen

SSH-Zertifizierungsstellen stellen Zertifikate in einem für das SSH-Protokoll spezifischen Format aus und bieten damit eine Alternative zur herkömmlichen SSH-Authentifizierung auf Schlüsselbasis. Anstatt einzelne öffentliche Schlüssel an jeden Server zu verteilen, können Unternehmen eine SSH-Zertifizierungsstelle nutzen, um kurzlebige Zertifikate auszustellen, denen jeder Server, der für die Erkennung dieser Zertifizierungsstelle konfiguriert ist, automatisch vertraut.

Zertifizierungsstellen für C-ITS-Registrierungen

C-ITS-Zertifikate (Cooperative Intelligent Transport Systems) verwenden ein von der EU festgelegtes Format für die Vehicle-to-Everything-Kommunikation (V2X). Diese speziellen Zertifikate ermöglichen eine sichere Kommunikation zwischen Fahrzeugen, Infrastruktur und Verkehrsmanagementsystemen und spielen eine entscheidende Rolle für die Sicherheit im Automobil- und Verkehrsbereich.

Einhaltung der Vorschriften für Zertifizierungsstellen und Sicherheitsstandards

Zertifizierungsstellen müssen strenge Sicherheits- und Compliance-Standards einhalten, um das Vertrauen zu wahren. Die Rahmenbedingungen für den Betrieb von Zertifizierungsstellen umfassen Branchenvorschriften, technische Standards und Anforderungen an die physische Sicherheit.

Branchen- und behördliche Standards

Zertifizierungsstellen arbeiten je nach Einsatzkontext unter Einhaltung verschiedener Rahmenwerke:

• DORA(Digital Operational Resilience Act): Gilt für Unternehmen des Finanzsektors in der gesamten EU und schreibt Maßnahmen zur digitalen Widerstandsfähigkeit vor, darunter PKI-Sicherheit.
• NIS2(Richtlinie über Netz- und Informationssicherheit): Erweitert die Anforderungen an die Cybersicherheit auf wesentliche und wichtige Einrichtungen in der EU.
• HIPAA(Health Insurance Portability and Accountability Act): Schreibt Verschlüsselung und Identitätskontrollen für Gesundheitsdaten vor, was sich unmittelbar darauf auswirkt, wie Zertifizierungsstellen in medizinischen Umgebungen eingesetzt werden.
• PCI/DSS(Payment Card Industry Data Security Standard): Schreibt die Verschlüsselung von Karteninhaberdaten vor und erfordert damit einen robusten Zertifizierungsstellenbetrieb für Zahlungsabwicklungssysteme.
• FedRAMP(Federal Risk and Authorization Management Program): Legt Sicherheitsstandards für Cloud-Dienste fest, die von US-Bundesbehörden genutzt werden.
• FIPS 140-2, 140-3:FIPS 140-2 definiert Sicherheitsanforderungen für kryptografische Module, einschließlich der hardware software , die von Zertifizierungsstellen (CAs) zur Schlüsselerzeugung und -speicherung software . Diese Anforderungen gelten auch weiterhin und werden in FIPS 140-3 in gewisser Weise noch verschärft.

Grundlegende Anforderungen des CA/Browser-Forums

Das CA/Browser Forum legt Standards fest, an die sich alle öffentlich anerkannten Zertifizierungsstellen halten müssen. Diese Baseline Requirements regeln die Verfahren zur Zertifikatsausstellung, die Validierungsverfahren und die technischen Vorgaben.

Eine wichtige Anforderung betrifft die Entropie der Zertifikatsseriennummer. Konforme Zertifikate müssen in ihren Seriennummern mindestens 64 Bit vollständig zufällige Informationen enthalten. Dies dient als Schutz vor hashbasierten Kollisionsangriffen auf die Zertifikatssignatur und stärkt die PKI gegen Präimage-Angriffe.

Hardware und Schlüsselschutz

Zertifizierungsstellen (CAs) lassen sich in hardware (HSMs) integrieren, um eine sichere Speicherung von Schlüsseln und kryptografische Vorgänge zu gewährleisten. HSMs bieten manipulationssichere Umgebungen, in denen private Schlüssel generiert, gespeichert und verwendet werden, ohne dass sie jemals im Klartext offengelegt werden.

Die Infrastrukturwartung für hochsichere CA-Bereitstellungen umfasst Offline-Stamm-CAs, die in physisch gesicherten Einrichtungen mit strengen Zugriffskontrollen, Umgebungsüberwachung und Audit-Protokollierung gehostet werden. Dieser mehrschichtige Ansatz stellt sicher, dass der vertrauenswürdige Stammanker auch dann geschützt bleibt, wenn Betriebssysteme kompromittiert werden.

Protokolle von Zertifizierungsstellen und technische Integration

Zertifizierungsstellen (CAs) unterstützen eine Reihe von Registrierungs- und Verwaltungsprotokollen, die automatisierte Zertifikatsvorgänge in großem Maßstab ermöglichen. Das geeignete Protokoll hängt von der Umgebung, den beteiligten Geräten und dem erforderlichen Automatisierungsgrad ab.

Gängige Prozeduren für die Einschreibung

• SCEP(Simple Certificate Enrollment Protocol): Wird häufig für die Geräteregistrierung verwendet, insbesondere in der Netzwerkinfrastruktur und bei der Verwaltung mobiler Geräte. SCEP ermöglicht es Geräten, Zertifikate mit minimalem manuellem Aufwand anzufordern und zu erhalten.
• CMP(Certificate Management Protocol): Ein standardbasiertes Protokoll, das den gesamten Lebenszyklus von Zertifikaten unterstützt, einschließlich Ausstellung, Verlängerung, Widerruf und Schlüsselwiederherstellung.
• EST(Enrollment over Secure Transport): Ein modernes, TLS Registrierungsprotokoll, das SCEP durch verbesserte Sicherheitsmerkmale ersetzen soll. EST nutzt HTTPS als Übertragungsprotokoll und unterstützt die Erneuerung von Zertifikaten sowie die erneute Registrierung.
• ACME(Automatic Certificate Management Environment): Ermöglicht die vollautomatische Ausstellung und Erneuerung von Zertifikaten; wird meist im Zusammenhang mit Let’s Encrypt genannt, findet jedoch zunehmend auch bei der Automatisierung interner PKI-Systeme Anwendung.
• Microsoft Auto-Enrollment:Integriert die Zertifikatsbereitstellung in Active Directory, sodass Zertifikate basierend auf den Gruppenrichtlinieneinstellungen automatisch an domänenangeschlossene Computer und Benutzer ausgestellt werden können.

Zertifikatsformate

Das X.509-Zertifikatsformat (definiert in RFC 5280) ist die gängigste Struktur für digitale Zertifikate. Ein X.509-Zertifikat enthält Felder wie den Distinguished Name des Zertifikatsinhabers, den Distinguished Name des Ausstellers, die Gültigkeitsdauer (Mindest- und Enddatum), den öffentlichen Schlüssel des Zertifikatsinhabers, eine Seriennummer sowie die digitale Signatur der Zertifizierungsstelle. Weitere gängige Zertifikatsformate sind unter anderem OpenPGP-Zertifikate, OpenSSH-Zertifikate und CVC-Zertifikate.

Die CSR (Certificate Signing Request), mit der der Ausstellungsvorgang eingeleitet wird, enthält identifizierende Angaben zum Antragsteller (wie beispielsweise einen Distinguished Name) sowie den vom Antragsteller bevorzugten öffentlichen Schlüssel. Die CSR muss mit dem privaten Schlüssel des Antragstellers signiert werden, um den Besitz des Schlüssels nachzuweisen.

Zertifizierungsstellen und neue Anwendungsfälle

Identität von IoT

In IoT bilden Zertifizierungsstellen (CAs) die Grundlage füreine sichere Geräteidentität. Jedes Gerät erhält bei der Herstellung oder Bereitstellung ein eindeutiges Zertifikat, das die gegenseitige Authentifizierung zwischen Geräten und Diensten ermöglicht.

Eine typische Umsetzung der CA-Hierarchie innerhalb eines IoT sieht wie folgt aus: Eine Root-CA (die offline betrieben wird) stellt Zertifikate für eine Product Attestation Authority (PAA) aus, die diese wiederum an Product Attestation Intermediates (PAIs) für verschiedene Produkttypen delegiert. Jede PAI stellt für jedes physische Gerät ein eindeutiges Device Attestation Certificate (DAC) aus. Die „Root of Trust“ des Geräts generiert ein öffentliches/privates Schlüsselpaar und eine CSR, die von der PKI des Herstellers signiert und als DAC zurückgesendet wird.

Dieser Ansatz stellt sicher, dass jedes verbundene Gerät über eine überprüfbare, eindeutige Identität verfügt, die in einer vertrauenswürdigen Zertifikatskette verankert ist – vom einzelnen Gerät bis hin zur Stamm-Zertifizierungsstelle des Herstellers.

Vorbereitung auf die Post-Quanten-Kryptografie

Angesichts der Fortschritte im Bereich des Quantencomputings müssen sich Zertifizierungsstellen auf den Übergang zu quantenresistenten Algorithmen vorbereiten. Aktuelle Algorithmen für öffentliche Schlüssel (RSA, ECDH, ECDSA usw.) sind anfällig für Angriffe durch ausreichend leistungsfähige Quantencomputer, was bedeutet, dass die heute von Zertifizierungsstellen ausgestellten Zertifikate letztendlich kompromittiert werden könnten.

Moderne CA-Plattformen unterstützen bereitspostquantenkryptografischeAlgorithmen. So EJBCA beispielsweise EJBCA postquantenkryptografische Signaturalgorithmen wie DILITHIUM5, die jedoch nur in Verbindung mit DILITHIUM5-Schlüsseln verwendet werden können. Zudem ist die hybride Zertifikatsausstellung verfügbar, bei der klassische und quantenresistente Signaturen in einem einzigen Zertifikat kombiniert werden. Dies ermöglicht es Unternehmen, sich bereits im Vorfeld der Quantenbedrohung kryptografisch flexibel aufzustellen.

Wie Keyfactor helfen Keyfactor

Die Verwaltung von Zertifizierungsstellen in großem Maßstab erfordert mehr als nur manuelle Prozesse. Keyfactor eine einheitlichePlattformfür Unternehmen, die öffentliche Zertifizierungsstellen, private Zertifizierungsstellen oder beides betreiben.

• EJBCA :Eine voll ausgestattete, skalierbare CA- und PKI-Plattform, die die Zertifikatstypen X.509, CVC, SSH und C-ITS unterstützt. EJBCA integrierte Sicherheitskontrollen, Automatisierung und Lebenszyklusmanagement sowie Unterstützung für mehrere Zertifizierungsstellen (CAs), Validierungsstellen und Registrierungsstellen innerhalb einer einzigen Bereitstellung.
• Keyfactor Command:Zentralisierte Übersicht und Verwaltung aller Zertifizierungsstellen (CAs) über eine einzige Benutzeroberfläche. Command öffentliche CAs (wie DigiCert), Microsoft-CAs und interne private CAs und bietet eine Zertifikatsbestandsaufnahme in Echtzeit, automatisierte Scans, Überwachung sowie Verlängerungsfunktionen mit einem Klick. Zudem integriert es Zertifizierungsstellen mit postquantenkryptografischen Algorithmen, darunter solche, die MLDSA-65 und hybride Algorithmen verwenden, und bietet Unternehmen damit einen Weg zur Quantenfestigkeit innerhalb ihrer bestehenden CA-Infrastruktur. Administratoren können Scan-Zeitpläne konfigurieren, Warnschwellen für die Massenausstellung festlegen und den Lebenszyklus von Zertifikaten unternehmensweit verwalten.
• PKI as a Service:Kombiniert verwaltete PKI und Zertifikatsautomatisierung und reduziert so den Betriebsaufwand für den Betrieb einer internen CA-Infrastruktur, während gleichzeitig die vollständige Kontrolle über den Zertifikatslebenszyklus gewahrt bleibt.
• Krypto-Agilität und Post-Quanten-Tauglichkeit:Die Unterstützung hybrider Zertifikate und quantenresistenter Algorithmen stellt sicher, dass Unternehmen ihre CA-Infrastruktur an die Weiterentwicklung der kryptografischen Standards anpassen können.

Fordern Sie eine Demo an, um zu erfahren, wie Keyfactor Ihre Zertifizierungsstellenabläufe modernisieren und Ihre PKI für die Zukunft rüsten Keyfactor .