AWS Certificate Manager Private CA

AWS Private CA (ehemals ACM Private CA) ist ein vollständig verwalteter privater Zertifizierungsstellendienst, mit dem Sicherheitsteams eine private PKI-Hierarchie innerhalb von AWS aufbauen und betreiben können, ohne Hardware für Zertifizierungsstellen kaufen oder verwalten zu müssen. Er stellt X.509-Zertifikate für internes TLS, mTLS, Codesignierung, IoT-Geräteidentität und Benutzerauthentifizierung aus. Für die meisten Teams empfiehlt sich als Ausgangspunkt eine zweistufige Hierarchie mit einer Stammzertifizierungsstelle innerhalb von AWS Private CA und einer oder mehreren untergeordneten Zertifizierungsstellen pro Umgebung. Zum Schutz der Zertifizierungsstellenschlüssel werden die vom Kunden verwalteten Schlüssel von AWS KMS verwendet. Für Organisationen mit strengen Anforderungen an die Schlüsselsouveränität bietet sich ein Hybridmodell (lokale Stammzertifizierungsstelle, untergeordnete Zertifizierungsstelle in AWS) an.

Kurzantwort: Was ist eine private AWS-Zertifizierungsstelle und wann sollte man sie verwenden?

AWS Private CA ist die richtige Wahl, wenn Sie private X.509-Zertifikate für interne Workloads ausstellen müssen, eine CA-Hierarchie benötigen, die Ihr Team nicht auf physischer Hardware betreiben muss, und primär in AWS arbeiten. Sie ist kein Ersatz für öffentliche TLS-Zertifikate (diese werden vom AWS Certificate Manager für integrierte Services kostenlos verwaltet). Nutzen Sie AWS Private CA für die Authentifizierung interner Services, mTLS zwischen Microservices, IoT-Gerätezertifikate, VPN-Benutzerzertifikate und Codesignierungsszenarien, in denen eine öffentlich vertrauenswürdige CA unnötig und unerwünscht ist. Der Service kostet 400 US-Dollar pro CA und Monat für allgemeine Zwecke und 50 US-Dollar pro CA und Monat für kurzlebige Zertifikate (gültig für maximal 7 Tage), zuzüglich gestaffelter Gebühren pro Zertifikat.

Wichtige Erkenntnisse

• AWS bietet zwei unterschiedliche Dienste an: AWS Certificate Manager (ACM) für kostenlose öffentliche TLS-Zertifikate, die mit integrierten AWS-Services verwendet werden, und AWS Private CA für private, intern vertrauenswürdige X.509-Zertifikate, die mit ihrem privaten Schlüssel exportiert und überall verwendet werden können.
• Es stehen zwei CA-Hierarchiemodelle zur Verfügung: Private Cloud (Root- und Subordinate-CAs in AWS Private CA, Schlüssel geschützt durch AWS KMS) und Hybrid Cloud (Root-CA lokal in Ihrem eigenen HSM, Subordinate-CAs in AWS Private CA). Das Hybrid-Modell ermöglicht Ihnen die direkte Kontrolle über den Root-CA-Schlüssel; das Private-Cloud-Modell bietet Ihnen vollständige Cloud-Automatisierung.
• Zwei Betriebsarten verändern die Kosten erheblich: Der allgemeine Modus für 400 $/CA/Monat unterstützt beliebige Zertifikatsgültigkeitsdauern. Der Modus für kurzlebige Zertifikate für 50 $/CA/Monat unterstützt ausschließlich Zertifikate mit einer Gültigkeit von maximal 7 Tagen und ist daher speziell für Service Mesh, SPIFFE-basierte Workload-Identität und Umgebungen mit hoher mTLS-Frequenz entwickelt und kostengünstig.
• Die Tastensteuerung ist eine Designentscheidung, keine Standardeinstellung: AWS Private CA nutzt AWS KMS zum Schutz von CA-Schlüsseln. Bei standardmäßig von AWS verwalteten Schlüsseln behält AWS die operative Kontrolle. Mit kundenverwalteten KMS-Schlüsseln (BYOK) besitzen Sie das Quellschlüsselmaterial und können die Signierberechtigung der CA durch Löschen des importierten Schlüssels sofort widerrufen. Ein vollständiges HYOK-Modell erfordert eine Hybrid-Cloud-Architektur mit einer lokalen Stammzertifizierungsstelle.
• Das CA/B Forum SC-081v3 befürwortet den kurzlebigen Modus für öffentlich zugängliche Zertifikate: Die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate sinkt ab März 2026 auf 200 Tage, ab März 2027 auf 100 Tage und ab März 2029 auf 47 Tage. Private Zertifizierungsstellen, die über AWS Private CA ausgestellt werden, können bereits an jeden Gültigkeitszeitraum angepasst werden; die Kombination mit einer Automatisierung des Zertifikatslebenszyklus ist angesichts der zunehmenden Erneuerungshäufigkeit unerlässlich.

AWS Certificate Manager vs. AWS Private CA: Zwei unterschiedliche Dienste

Die Verwechslung dieser beiden Dienste ist weit verbreitet und hat schwerwiegende Folgen. Sie dienen unterschiedlichen Zwecken, haben unterschiedliche Preismodelle und sind nicht austauschbar.

AWS Certificate Manager (ACM) stellt öffentliche SSL/TLS-Zertifikate für die Verwendung mit AWS-integrierten Diensten wie Amazon CloudFront, Application Load Balancer, Amazon API Gateway und AWS Elastic Beanstalk bereit und erneuert diese. Öffentliche Zertifikate über ACM sind für die Nutzung mit diesen integrierten Diensten kostenlos. Die Erneuerung erfolgt automatisch durch ACM. Wichtiger Hinweis: Sie können weder ein von ACM verwaltetes öffentliches Zertifikat noch dessen privaten Schlüssel exportieren. ACM-Zertifikate lassen sich nicht direkt auf EC2-Instanzen, lokalen Servern oder Nicht-AWS-Systemen installieren. Außerdem können sie keine Zertifikate für interne Hostnamen oder private IP-Adressen ausstellen, die die Validierung öffentlicher Domains nicht bestehen würden.

AWS Private CA ist ein verwalteter Dienst zum Betrieb einer privaten Zertifizierungsstelle. Die von ihr ausgestellten Zertifikate sind privat vertrauenswürdig (die Geräte und Dienste Ihrer Organisation müssen so konfiguriert sein, dass sie der CA-Hierarchie vertrauen). Der private Schlüssel kann zusammen mit dem Zertifikat exportiert werden, sodass die Installation überall möglich ist: auf EC2-Instanzen, lokalen Servern, Containern, IoT-Geräten und in benutzerdefinierten Anwendungen. AWS Private CA unterstützt private Hostnamen, interne IP-Adressen und benutzerdefinierte Subjektfelder, die von öffentlichen Zertifizierungsstellen nicht ausgestellt werden können. Es wird eine monatliche Betriebsgebühr für die Zertifizierungsstelle sowie eine Gebühr pro ausgestelltem Zertifikat erhoben.

Abmessungen	AWS Certificate Manager (ACM)	AWS Private CA
Zertifikatsvertrauen	Öffentlich vertrauenswürdig (Browser- und Betriebssystem-Vertrauensspeicher)	Privat vertrauenswürdig (nur Ihre CA-Hierarchie)
Export des privaten Schlüssels	Nicht gestattet	Zulässig (Zertifikat + Schlüssel exportierbar)
Gültig für interne Hostnamen	Nein	Ja
Kosten	Kostenlos für ACM-integrierte Dienste	400 $/CA/Monat (allgemein) oder 50 $/CA/Monat (kurzfristig)
Automatische Erneuerung	Ja (verwaltet von AWS)	Erfordert CLM-Automatisierung oder manuelle Verlängerung
Anwendungsfälle	Öffentliches HTTPS für Websites und APIs auf AWS-Diensten	Internes TLS, mTLS, IoT, Codesignierung, VPN, Benutzerauthentifizierung
CA Schlüsselverwahrung	AWS-verwaltet (kein Kundenzugriff)	AWS KMS (vom Kunden verwaltete Schlüssel werden unterstützt)

CA-Hierarchiemodelle: Private Cloud vs. Hybrid Cloud

AWS Private CA unterstützt zwei grundlegende Architekturen für die CA-Hierarchie. Die Wahl zwischen diesen Architekturen ist die wichtigste Designentscheidung, da sie festlegt, wer den Root-CA-Schlüssel verwahrt und wie viel operative Komplexität Sie akzeptieren.

Modell 1: Private Cloud (Root- und Subordinate-CAs beide in AWS)

In diesem Modell erstellen Sie eine Stammzertifizierungsstelle (Root CA) innerhalb von AWS Private CA und eine oder mehrere untergeordnete (ausstellende) Zertifizierungsstellen, alle innerhalb von AWS. Der Schlüssel der Stammzertifizierungsstelle wird durch AWS KMS geschützt. AWS übernimmt Hochverfügbarkeit, Replikation und Schlüsselschutz. Die Interaktion mit der Zertifizierungsstelle erfolgt ausschließlich über die AWS-Konsole, das SDK und die CLI.

Dieses Modell bietet die Vorteile der vollständigen Cloud-Automatisierung: keine Hardwareverwaltung, kein HSM-Provisioning, automatische Hochverfügbarkeit über alle Availability Zones hinweg und API-gesteuerte Zertifikatsausstellung mit nativer Integration in AWS-Services. Der Nachteil besteht darin, dass der Root-CA-Schlüssel im AWS KMS im Rahmen des Modells der geteilten Verantwortung gespeichert wird. AWS hat als Teil des Managed Service operativen Zugriff auf das Schlüsselmaterial. Für Organisationen, deren regulatorische Anforderungen vorschreiben, dass der Root-CA-Schlüssel ausschließlich vom Kunden gehalten werden muss, erfüllt dieses Modell diese Anforderungen nicht, es sei denn, Sie verwenden kundenverwaltete KMS-Schlüssel (BYOK).

AWS Private CA unterstützt bis zu fünf Ebenen in einer Zertifizierungsstellenhierarchie: eine Stammzertifizierungsstelle mit bis zu vier untergeordneten Zertifizierungsstellen. Sie können mehrere unabhängige Hierarchien erstellen, jede mit ihrer eigenen Stammzertifizierungsstelle. Für die meisten Unternehmen ist eine zweistufige Hierarchie (Stammzertifizierungsstelle plus eine ausstellende Zertifizierungsstelle pro Umgebung) ausreichend und einfacher zu prüfen.

Modell 2: Hybrid Cloud (Lokale Stammzertifizierungsstelle, AWS-Unterzertifizierungsstelle)

In diesem Modell wird die Stammzertifizierungsstelle (Root CA) lokal gehostet, typischerweise in einem dedizierten HSM unter Ihrer direkten physischen und logischen Kontrolle. Die untergeordnete Zertifizierungsstelle wird in AWS Private CA erstellt, und Sie signieren deren Zertifikatsignierungsanforderung (CSR) mit Ihrer lokalen Stammzertifizierungsstelle. Das resultierende signierte Zertifikat der untergeordneten Zertifizierungsstelle wird wieder in AWS Private CA importiert und aktiviert diese für die operative Zertifikatsausstellung.

Dieses Modell ermöglicht Ihnen die direkte Kontrolle über den Root-CA-Schlüssel. Dieser Schlüssel gelangt niemals in AWS. Sollte die untergeordnete Zertifizierungsstelle der AWS Private CA kompromittiert werden, kann ein Angreifer keine neuen Zertifikate auf Root-Ebene ausstellen, und Sie können das untergeordnete Zertifikat mithilfe Ihrer lokalen Root-CA unabhängig von AWS widerrufen. Die damit verbundenen Kompromisse sind jedoch erheblich: Sie müssen die lokale Root-CA-Infrastruktur betreiben und warten, dokumentierte Root-CA-Zeremonien für alle Root-CA-Schlüsseloperationen durchführen und die physische und logische Sicherheit des lokalen HSM gewährleisten. Für Organisationen mit einer bestehenden lokalen PKI, die teilweise zu AWS migrieren, bietet das Hybrid-Cloud-Modell eine nahtlose Überbrückung, ohne dass eine vollständige Änderung des Vertrauensmodells erforderlich ist.

Schlüsselverwaltung: Natives KMS, BYOK und HYOK für AWS Private CA

AWS Private CA schützt CA-Privatschlüssel mithilfe von AWS KMS. Die Wahl des KMS-Schlüsseltyps bestimmt Ihren Kontrollgrad über das CA-Schlüsselmaterial und Ihre Möglichkeit, den Zugriff unabhängig zu widerrufen.

Option 1: AWS-verwalteter KMS-Schlüssel (Standard)

Wenn Sie eine private Zertifizierungsstelle (CA) ohne Angabe eines KMS-Schlüssels erstellen, generiert und verwaltet AWS Private CA automatisch einen KMS-Schlüssel für Sie. Dieser Schlüssel ist Ihrer CA zugeordnet, wird aber vollständig von AWS verwaltet. Sie können den Schlüssel weder einsehen, noch unabhängig rotieren oder löschen, ohne die CA zu löschen. Dies ist die einfachste Option und erfüllt die meisten betrieblichen Anforderungen. Sie ermöglicht es Ihnen jedoch nicht, die Signaturberechtigung der CA unabhängig zu widerrufen, außer durch Löschen der CA über die AWS-Konsole oder die API.

Option 2: Vom Kunden verwalteter KMS-Schlüssel (BYOK)

BYOK (Bring Your Own Key) für AWS Private CA bedeutet, dass Sie einen kundenseitig verwalteten Schlüssel (CMK) in AWS KMS erstellen, entweder von AWS KMS generiert oder aus einer externen Schlüsselquelle importiert, und diesen CMK bei der Erstellung der privaten Zertifizierungsstelle angeben. AWS Private CA verwendet Ihren CMK zum Schutz des privaten Schlüssels der Zertifizierungsstelle.

Mit einem kundenverwalteten CMK können Sie den Schlüssel deaktivieren, um die Zertifizierungsstelle (CA) sofort an der Durchführung von Signaturvorgängen zu hindern, ohne die CA zu löschen. Die Schlüsselnutzung können Sie in AWS CloudTrail einsehen. Sie steuern die Schlüsselrotation für den CMK. Wenn Sie importiertes Schlüsselmaterial verwenden (den Schlüssel extern generieren und in den KMS importieren), behalten Sie das ursprüngliche Schlüsselmaterial und können das importierte Schlüsselmaterial aus dem KMS löschen, um die Signaturberechtigung der CA dauerhaft und sofort zu widerrufen – auch ohne Unterstützung des AWS-Supports.

BYOK ist die richtige Wahl für Organisationen, die einen unabhängigen Not-Aus-Schalter für den CA-Schlüssel benötigen, die regulatorische Anforderungen an kundengeneriertes Schlüsselmaterial haben oder die den Prüfern nachweisen müssen, dass die Organisation die Herkunft aller kryptografischen Schlüssel behält, die ihre CA-Infrastruktur schützen.

Option 3: HYOK (Hold Your Own Key) über Hybridarchitektur

Echtes HYOK für eine Stammzertifizierungsstelle, bei dem der CA-Schlüssel unter keinen Umständen in AWS gelangt, erfordert die oben beschriebene Hybrid-Cloud-Architektur: Die Stammzertifizierungsstelle und ihr Schlüssel befinden sich in einem lokalen HSM, das Sie kontrollieren, und nur untergeordnete Zertifizierungsstellen werden in AWS Private CA gehostet. Die untergeordneten Zertifizierungsstellen in AWS Private CA verwenden weiterhin einen KMS-gestützten Schlüssel (den Sie als kundenverwalteten CMK erstellen können), aber der Schlüssel der Stammzertifizierungsstelle befindet sich vollständig außerhalb der AWS-Infrastruktur.

Dies gewährleistet höchste Schlüsselhoheit auf der Ebene der Stammzertifizierungsstelle. AWS kann unter keinen Umständen auf den Schlüssel der Stammzertifizierungsstelle zugreifen oder ihn verwenden, auch nicht bei rechtlichem Zwang gegen AWS. Der Nachteil besteht in der erhöhten betrieblichen Komplexität der Wartung einer lokalen Stammzertifizierungsstelle und der Latenz des umgebungsübergreifenden Signaturprozesses für untergeordnete Zertifizierungsstellen.

Abmessungen	AWS-verwalteter KMS-Schlüssel	Kundenseitig verwalteter KMS-Schlüssel (BYOK)	HYOK (Lokale Stammzertifizierungsstelle)
CA-Schlüsselposition	AWS KMS (von AWS verwaltet)	AWS KMS (vom Kunden verwaltet)	Stammschlüssel: Ihr lokales HSM; Unterschlüssel: AWS KMS
AWS-Zugriff auf den Root-Schlüssel	Ja (betriebsbereit)	Ja (operative, kundenseitige Kontrolle über Rotation und Löschung)	Nein für Root-CA-Schlüssel
Unabhängiger Not-Aus-Schalter	Nur CA löschen (AWS-vermittelt)	CMK deaktivieren oder löschen (sofort, unabhängig)	Untergeordnetes CA-Zertifikat vom lokalen Stammzertifizierungszentrum widerrufen (sofort)
Wichtige Herkunftskontrolle	AWS generiert wichtiges Material	Der Kunde generiert oder importiert wichtiges Material	Der Kunde generiert und verwahrt den Root-Schlüssel exklusiv.
Operative Komplexität	Niedrig	Medium	Hoch (erfordert HSM und Zeremonieninfrastruktur vor Ort)
Am besten geeignet,	Die meisten AWS-nativen Workloads; Priorität: operative Einfachheit	Regulierte Sektoren; unabhängige Schlüsselkontrollanforderung	Strenge Souveränitätsvorgaben; klassifizierte oder abgeschottete Umgebungen

IAM-Modell für private AWS-Zertifizierungsstellen: Prinzip der minimalen Berechtigungen

Die Zugriffskontrolle für private AWS-Zertifizierungsstellen verwendet IAM-Identitätsrichtlinien und ressourcenbasierte Richtlinien. Um ein Zugriffsrecht mit minimalen Berechtigungen zu gewährleisten, müssen die Rollen, die die Zertifizierungsstelle verwalten, von den Rollen, die Zertifikate ausstellen, getrennt werden.

Rolle des CA-Administrators: Benötigt Berechtigungen zum Erstellen, Aktualisieren, Taggen und Löschen von Zertifizierungsstellen sowie zum Importieren von Zertifizierungsstellenzertifikaten. Wichtige Berechtigungen: acm-pca:CreateCertificateAuthority, acm-pca:UpdateCertificateAuthority, acm-pca:DeleteCertificateAuthority, acm-pca:ImportCertificateAuthorityCertificate, acm-pca:TagCertificateAuthorityDiese Rolle darf nicht vergeben werden. acm-pca:IssueCertificate um die Funktionstrennung aufrechtzuerhalten.

Rolle des Zertifikatsausstellers: Benötigt Berechtigungen zum Ausstellen und Abrufen von Zertifikaten sowie zur Konfiguration des Zertifikatswiderrufs. Wichtige Berechtigungen: acm-pca:IssueCertificate, acm-pca:GetCertificate, acm-pca:RevokeCertificate, acm-pca:ListCertificateAuthoritiesFür diese Rolle dürfen keine CA-Verwaltungsberechtigungen erteilt werden.

Ausstellung von kontoübergreifenden Zertifikaten: Wenn eine untergeordnete Zertifizierungsstelle in einem AWS-Konto Zertifikate für Workloads in einem anderen AWS-Konto ausstellen muss, muss eine ressourcenbasierte Richtlinie für die private Zertifizierungsstelle dies explizit gewähren. acm-pca:IssueCertificate an den Hauptverantwortlichen im anfragenden Konto. Dies ist das korrekte Vorgehen für Plattformteams, die einen gemeinsam genutzten PKI-Dienst über mehrere AWS-Konten in einer AWS-Organisationsstruktur betreiben.

KMS-Schlüsselrichtlinienintegration: Wenn Sie einen vom Kunden verwalteten KMS-Schlüssel für den Schutz von CA-Schlüsseln verwenden, muss die KMS-Schlüsselrichtlinie dem AWS Private CA-Dienstprinzipal die Berechtigung zur Verwendung des Schlüssels erteilen. kms:Sign Die Trennung des KMS-Schlüsseladministrators (der die Schlüsselrichtlinie verwalten kann) vom KMS-Schlüsselbenutzer (dem privaten CA-Dienst) verhindert, dass ein einzelner Akteur sowohl den Schlüssel kontrolliert als auch Zertifikate ausstellt.

Allgemeiner Modus vs. Modus für kurzlebige Zertifikate

AWS Private CA hat einen zweiten Betriebsmodus speziell für Workloads mit häufigen, kurz gültigen Zertifikaten eingeführt. Die Wahl des richtigen Modus für jede Zertifizierungsstelle in Ihrer Hierarchie hat erhebliche Auswirkungen auf Kosten und Architektur.

Der allgemeine Modus (400 $/CA/Monat) unterstützt die Ausstellung von Zertifikaten mit beliebiger Gültigkeitsdauer, von Sekunden bis zu Jahren. Er eignet sich für klassische PKI-Anwendungsfälle: TLS-Serverzertifikate, Benutzerauthentifizierungszertifikate, Codesignaturzertifikate und Geräteidentitätszertifikate mit mehrjähriger oder mehrmonatiger Gültigkeitsdauer. Er unterstützt alle Zertifikatvorlagen und die gesamte Bandbreite an Schlüsselalgorithmen (RSA 2048, RSA 4096, ECDSA P-256, ECDSA P-384).

Der Modus für kurzlebige Zertifikate (50 $/CA/Monat) beschränkt die Gültigkeitsdauer auf maximal 7 Tage. Diese Einschränkung ist besonders für Umgebungen mit SPIFFE/SPIRE-basierter Workload-Identität, Service-Mesh-mTLS (Istio, Linkerd) oder zertifikatsbasierten, temporären Anmeldeinformationen geeignet, da die kurze Gültigkeitsdauer die Notwendigkeit einer Widerrufsprüfung vollständig eliminiert. Mit nur einem Achtel der Kosten des Standardmodus bietet der Modus für kurzlebige Zertifikate eine erhebliche Kostenoptimierung für Umgebungen mit häufigem, automatisiertem Zertifikatsausstellungsbedarf. Die Kombination einer Zertifizierungsstelle im Modus für kurzlebige Zertifikate mit einem ACME- oder EST-Registrierungsprotokoll und einer CLM-Plattform zur Zertifikatsautomatisierung bildet die Produktionsarchitektur für moderne Cloud-native PKI.

Welche Zertifikatstypen und Anwendungsfälle kann eine private AWS-Zertifizierungsstelle ausstellen?

AWS Private CA unterstützt die folgenden Zertifikatstypen über konfigurierbare Vorlagen, die die korrekte Schlüsselverwendung und erweiterte Schlüsselverwendungserweiterungen erzwingen:

• TLS-Serverzertifikate: Interne Webserver, APIs und Microservices, die HTTPS mit privatem Vertrauen benötigen. Das Zertifikat enthält die TLS-Serverauthentifizierungs-EKU (OID 1.3.6.1.5.5.7.3.1) und wird von Clients validiert, die Ihrer privaten CA-Hierarchie vertrauen.
• mTLS-Clientzertifikate: Gegenseitige TLS-Authentifizierung zwischen Diensten in Microservice-Architekturen und Service-Meshes. Beide Seiten legen Zertifikate vor; die TLS-Client-Authentifizierungs-EKU (OID 1.3.6.1.5.5.7.3.2) ist enthalten. Der Modus mit kurzlebigen Zertifikaten ist optimal für mTLS-Workload-Identitätszertifikate, die in einem Zyklus von unter 24 Stunden erneuert werden.
• IoT-Gerätezertifikate: Bereitstellung von Geräteidentitäten während der Fertigung und Authentifizierung von Feldgeräten. AWS Private CA integriert sich in AWS IoT Core für die Zertifikatsausstellung im Flottenmaßstab. Die IEEE 802.1AR IDevID- und LDevID-Muster sind über die API realisierbar.
• Code-Signing-Zertifikate: Interne Software-Artefaktsignierung für CI/CD-Pipelines und Firmware-Verteilung. Die Codesignierung über eine private AWS-Zertifizierungsstelle erfordert die Code Signing EKU (OID 1.3.6.1.5.5.7.3.3) und einen geeigneten Schlüsselschutz für den Signaturschlüssel.
• E-Mail-Schutz (S/MIME): Interne E-Mail-Verschlüsselung mittels Zertifikaten mit der Email Protection EKU (OID 1.3.6.1.5.5.7.3.4). Für unternehmensweite S/MIME-Verschlüsselung bietet Encryption Consulting die entsprechende Lösung an. CertSecure Manager bietet die CLM-Ebene für die Registrierung und das Lebenszyklusmanagement.
• OCSP-Signaturzertifikate: Erforderlich, wenn Sie den verwalteten OCSP-Responder von AWS Private CA konfigurieren. Die OCSP Signing EKU (OID 1.3.6.1.5.5.7.3.9) ist automatisch in den vom Dienst ausgestellten OCSP-Signaturzertifikaten enthalten.

OCSP und Zertifikatswiderruf in einer privaten AWS-Zertifizierungsstelle

AWS Private CA unterstützt zwei Widerrufsmechanismen, die pro CA unabhängig aktiviert werden können.

Managed OCSP ist der von AWS gehostete OCSP-Responder (Online Certificate Status Protocol). Ist dieser aktiviert, stellt die private AWS-Zertifizierungsstelle automatisch OCSP-Signaturzertifikate aus, veröffentlicht die OCSP-Responder-URL in der AIA-Erweiterung (Authority Information Access) der ausgestellten Zertifikate und beantwortet OCSP-Anfragen zum Zertifikatsstatus. Managed OCSP kostet 0.06 US-Dollar pro Zertifikat und Monat, sofern OCSP-Antworten für dieses Zertifikat generiert wurden, zuzüglich 0.20 US-Dollar pro 100,000 OCSP-Anfragen. In Umgebungen mit hohem mTLS-Aufkommen, in denen jede Verbindung eine OCSP-Prüfung auslöst, summieren sich diese Kosten schnell. Der Modus für kurzlebige Zertifikate umgeht OCSP vollständig, da Zertifikate ablaufen, bevor ein Widerruf relevant wird.

Die CRL (Certificate Revocation List) ist der alternative Widerrufsmechanismus. Eine private AWS-Zertifizierungsstelle kann CRLs nach einem konfigurierbaren Zeitplan in einem Amazon S3-Bucket veröffentlichen. Die CRL-Verteilung erfordert, dass der S3-Bucket für alle Zertifikatsinhaber zugänglich ist. Dies bedeutet in der Regel, dass der Bucket für öffentlichen oder eingeschränkten Zugriff konfiguriert werden muss. Die CRL-Prüfung führt zu einer zusätzlichen Latenz beim Verbindungsaufbau, die der Zeit entspricht, die zum Herunterladen und Überprüfen der CRL benötigt wird.

Für die meisten privaten PKI-Implementierungen in Unternehmen ist Managed OCSP der bevorzugte Sperrmechanismus, da er Echtzeitstatus bereitstellt, ohne dass Clients potenziell große CRL-Dateien herunterladen und zwischenspeichern müssen. In abgeschotteten oder hochsensiblen Umgebungen, in denen ausgehende OCSP-Abfragen unerwünscht sind, stellt eine CRL mit kurzer Gültigkeitsdauer (tägliche oder stündliche Veröffentlichung) die geeignete Alternative dar.

Kostenaufschlüsselung für private AWS-Zertifizierungsstellen

Um die Gesamtkosten einer privaten AWS-Zertifizierungsstelle zu ermitteln, müssen die Kosten für den CA-Betrieb, die Zertifikatsausstellung, OCSP und die KMS-Schlüsseloperationen zum Schutz des privaten CA-Schlüssels berücksichtigt werden. Die ursprüngliche Angabe von 400 US-Dollar pro Monat deckt lediglich die Betriebskosten der Zertifizierungsstelle im allgemeinen Modus ab.

Kostenkomponente	Universalmodus	Modus für kurzlebige Zertifikate
CA-Operation (pro CA pro Monat)	$400	$50
Zertifikate 1 bis 1,000 (pro Zertifikat)	$0.75	0.058 $ (Pauschalpreis)
Zertifikate 1,001 bis 10,000 (pro Zertifikat)	$0.35	0.058 $ (Pauschalpreis)
Zertifikate 10,001 und höher (pro Zertifikat)	$0.001	0.058 $ (Pauschalpreis)
OCSP (pro Zertifikat und Monat, falls angefragt)	$0.06	Nicht zutreffend (Zertifikate laufen ab, bevor OCSP benötigt wird)
OCSP-Anfragen (pro 100,000)	$0.20	N / A
Kostenlose Testversion	30 Tage für die erste Zertifizierungsstelle pro Konto und Region (nur für den Betrieb der Zertifizierungsstelle; Zertifizierungsgebühren fallen weiterhin an).	30 Tage für die erste Zertifizierungsstelle pro Konto und Region

Ein praktisches Beispiel: Eine Zwei-CA-Hierarchie (Root-CA plus eine ausstellende CA) im allgemeinen Modus, die monatlich 2,000 Zertifikate mit aktiviertem OCSP ausstellt, kostet ca. 800 US-Dollar (CA-Betrieb) zuzüglich 1,025 US-Dollar Zertifikatsgebühren (1,000 x 0.75 US-Dollar plus 1,000 x 0.35 US-Dollar) zuzüglich OCSP-Kosten (2,000 x 0.06 US-Dollar = 120 US-Dollar), insgesamt also rund 1,945 US-Dollar pro Monat vor KMS-Gebühren. Bei einer unkontrollierten Ausbreitung der CAs, bei der jede Umgebung eine eigene untergeordnete CA erhält, vervielfachen sich die monatlichen CA-Betriebskosten von 400 US-Dollar auf alle CAs. Die Konsolidierung von Umgebungen unter einer einzigen untergeordneten CA, sofern die Sicherheitsrichtlinien dies zulassen, reduziert die Kosten erheblich.

Die aktuelle Preisseite finden Sie unter aws.amazon.com/private-ca/pricing/.

Integration des Zertifikatslebenszyklusmanagements

AWS Private CA stellt die CA-Infrastruktur bereit, jedoch sind für das Zertifikatslebenszyklusmanagement (CLM) zusätzliche Tools erforderlich. Da das CA/B Forum SC-081v3 die maximale Gültigkeitsdauer öffentlicher TLS-Zertifikate ab März 2026 auf 200 Tage, ab März 2027 auf 100 Tage und ab März 2029 auf 47 Tage reduziert, ist die automatische Verlängerung auch für private Zertifikate, die parallel zu öffentlichen Zertifikaten verwendet werden, nicht mehr optional.

AWS Private CA integriert sich nativ mit verschiedenen Registrierungsmechanismen:

• AWS Certificate Manager-Integration: ACM kann eine private Zertifizierungsstelle als ausstellende Zertifizierungsstelle für Zertifikate verwenden, die automatisch für in ACM integrierte Dienste bereitgestellt werden. Dies gewährleistet privates Vertrauen in Verbindung mit der automatisierten Zertifikatserneuerung und -bereitstellung von ACM.
• ACME-Protokoll: Der AWS Private CA Connector für ACME (veröffentlicht 2023) ermöglicht ACME-kompatiblen Clients (cert-manager, certbot, acme.sh), Zertifikate von Ihrer privaten Zertifizierungsstelle über das Standard-ACME-Protokoll anzufordern. Dies ist der optimale Integrationspfad für die native Zertifikatsautomatisierung in Kubernetes und für DevOps-Toolchains.
• Active Directory (AD CS)-Integration: AWS Private CA Connector für Active Directory integriert sich in Microsoft AD-eingebundene Windows-Umgebungen und ermöglicht es Domänenbenutzern und -rechnern, Zertifikate von AWS Private CA über die bekannten AD Certificate Services-Registrierungsmechanismen (automatische Registrierung, SCEP) zu erhalten.
• Direkte API und SDK: Die AWS Private CA API unterstützt die programmatische Zertifikatsausstellung über das SDK in jeder von AWS unterstützten Sprache und ermöglicht so benutzerdefinierte Registrierungsabläufe für nicht standardisierte Systeme.

Für Organisationen, die Zertifikate über AWS Private CA und andere Zertifizierungsstellen (Microsoft AD CS, lokale PKI, Cloud-Anbieter-Zertifizierungsstellen) verwalten, bietet der CertSecure Manager von Encryption Consulting eine CA-unabhängige, einheitliche Zertifikatserkennung, Lebenszyklusautomatisierung und Ablaufüberwachung über alle Quellen hinweg. Die AWS Private CA-Volumes sollten in jedes unternehmensweite CLM-Inventar aufgenommen werden.

Multi-Cloud- und Hybrid-PKI-Architektur

Organisationen, die AWS Private CA neben Azure, GCP oder On-Premises-Umgebungen betreiben, stehen vor demselben Problem der Cloud-übergreifenden Konsistenz wie bei jedem Cloud-nativen Schlüsselverwaltungsdienst: AWS Private CA ist AWS-spezifisch. Die von ihr ausgestellten Zertifikate werden von Systemen, die Ihrer privaten CA-Hierarchie vertrauen, als vertrauenswürdig eingestuft. Die CA-Verwaltungsebene, das Audit-Trail und die Lebenszyklusautomatisierung sind jedoch AWS-nativ und lassen sich nicht automatisch auf andere Clouds übertragen.

Drei Muster befassen sich mit diesem Thema für Multi-Cloud-PKI:

• Eine einzige AWS Private CA-Hierarchie als Unternehmensstamm: Alle Umgebungen (AWS, Azure, GCP, On-Premises) vertrauen derselben Stammzertifizierungsstelle, die in einer privaten AWS-Zertifizierungsstelle gehostet wird. Untergeordnete Zertifizierungsstellen stellen Zertifikate für jede Umgebung aus. Die cloudübergreifende Zertifikatsverteilung erfolgt durch die Bereitstellung des Stammzertifikats in den Vertrauensspeichern aller Systeme. Dies ist das einfachste Modell für Organisationen, die primär auf AWS basieren und andere Umgebungen als Satellitenbereitstellungen behandeln.
• Lokale Stammzertifizierungsstelle mit untergeordneten Cloud-Zertifizierungsstellen: Eine lokale Stammzertifizierungsstelle signiert untergeordnete Zertifizierungsstellenzertifikate für AWS Private CA (für AWS-Workloads), Azure-basierte untergeordnete Zertifizierungsstellen (für Azure-Workloads) und alle anderen Cloud-Umgebungen. Alle untergeordneten Zertifizierungsstellen nutzen dieselbe Vertrauensbasis, arbeiten aber unabhängig voneinander innerhalb ihrer jeweiligen Cloud-Plattformen. Dies ist das Hybrid-Cloud-Modell, erweitert auf mehrere Clouds. Die lokale Stammzertifizierungsstelle bildet den ultimativen Vertrauensanker.
• CLM-vereinheitlichte Multi-CA-Landschaft: Jede Cloud nutzt ihren nativen CA-Dienst (AWS Private CA für AWS, Azure Active Directory Certificate Services oder Azure-integrierte CAs für Azure, GCP Certificate Authority Service für GCP). Eine cloudunabhängige CLM-Plattform aggregiert den Zertifikatsbestand, überwacht das Ablaufdatum und setzt die Rotationsrichtlinie über alle Quellen hinweg durch. Dadurch wird die Komplexität einer cloudübergreifenden CA-Hierarchie vermieden, allerdings ist eine CLM-Plattform erforderlich, die sich in mehrere CA-APIs integrieren lässt. (Encryption Consulting) CertSecure Manager Integriert sich mit AWS Private CA und anderen CA-Quellen, um diese einheitliche Transparenzebene bereitzustellen.

ACM Private CA Best Practices

1. Entwerfen Sie Ihre CA-Hierarchie vor der Bereitstellung: Entscheiden Sie, wie viele Zertifizierungsstellenebenen Sie benötigen (für die meisten Unternehmen wird ein zweistufiges System empfohlen: Stammzertifizierungsstelle plus ausstellende Zertifizierungsstelle pro Umgebung), wie viele untergeordnete Zertifizierungsstellen erstellt werden sollen und welche Umgebungen eine ausstellende Zertifizierungsstelle gemeinsam nutzen bzw. dedizierte Zertifizierungsstellen erhalten. Eine unkontrollierte Ausbreitung von Zertifizierungsstellen vervielfacht Ihre monatlichen Betriebskosten und erschwert den Widerruf.
2. Dokumentieren Sie Ihre Zertifizierungsrichtlinien und -praktiken: Definieren Sie maximale Gültigkeitsdauern pro Zertifikatstyp, zulässige Schlüsselalgorithmen und -längen, zulässige erweiterte Schlüsselverwendungen pro Zertifikatvorlage sowie den Genehmigungsworkflow für jede Zertifikatskategorie. AWS Private CA setzt diese Vorgaben mithilfe von Vorlagen und API-Steuerungen durch; die Richtliniendokumentation dient den Auditoren zur Überprüfung.
3. Verwenden Sie kundenverwaltete KMS-Schlüssel zum Schutz von CA-Schlüsseln: Die standardmäßig von AWS verwalteten Schlüssel funktionieren zwar, bieten aber weniger Kontrolle. Kundenseitig verwaltete Schlüssel ermöglichen das unabhängige Deaktivieren/Löschen und bieten einen übersichtlicheren Prüfpfad für Schlüsselvorgänge in CloudTrail.
4. Aktivieren Sie CloudTrail für alle Aktivitäten der privaten CA-API: Jede Zertifikatsausstellung, jeder Zertifikatswiderruf, jede CA-Erstellung und jede CA-Konfigurationsänderung generiert ein CloudTrail-Ereignis. Leiten Sie diese an ein SIEM-System weiter und konfigurieren Sie Warnungen für Zertifikatsausstellungen durch unerwartete Benutzer, CA-Löschanforderungen und KMS-Schlüsseldeaktivierungsereignisse für Schlüssel, die die privaten CA-Schlüssel schützen.
5. Automatisierte Zertifikatserneuerung vor Ablauf: AWS Private CA erneuert die von ihr ausgestellten Zertifikate nicht automatisch (anders als ACM für öffentliche Zertifikate). Verwenden Sie den ACME-Connector, die ACM-Integration oder eine CLM-Plattform, um die Erneuerung zu automatisieren. Bei einer Zertifikatsgültigkeit von 47 Tagen (gültig ab März 2029 für öffentliche Zertifikate) ist eine manuelle Erneuerung aus betrieblicher Sicht nicht möglich. Implementieren Sie die Automatisierung jetzt.
6. Separate IAM-Rollen für CA-Administrator und Zertifikatsaussteller: Kein einzelner IAM-Prinzipal sollte sowohl über Berechtigungen zur Zertifizierungsstellenverwaltung als auch zur Zertifikatsausstellung verfügen. Konfigurieren Sie separate Rollen und fordern Sie für sensible Zertifizierungsstellen die Multi-Faktor-Authentifizierung (MFA) für alle Verwaltungsvorgänge an.
7. Die Stammzertifizierungsstelle sollte deaktiviert bleiben, wenn sie nicht verwendet wird: Wenn Ihre Stammzertifizierungsstelle in AWS Private CA nicht regelmäßig Zertifikate für untergeordnete Zertifizierungsstellen ausstellen muss, deaktivieren Sie sie nach der anfänglichen Einrichtung der Hierarchie. Eine deaktivierte Stammzertifizierungsstelle kann keine Zertifikate ausstellen, wodurch die Angriffsfläche verringert wird. Aktivieren Sie sie nur wieder, wenn untergeordnete Zertifizierungsstellen erneuert oder die Hierarchie geändert wird.
8. Planen Sie den Einsatz in mehreren Regionen: AWS Private CA ist ein regionaler Service. Wenn sich Ihre Zertifikatslandschaft über mehrere AWS-Regionen erstreckt, erstellen Sie untergeordnete Zertifizierungsstellen in jeder Region, in der die Zertifikatsausstellungsverzögerung relevant ist. Die Stammzertifizierungsstelle kann in einer Region verbleiben; für untergeordnete Zertifizierungsstellen in anderen Regionen fallen jeweils eigene Betriebsgebühren in Höhe von 400 US-Dollar pro Monat (bzw. 50 US-Dollar pro Monat) an.

Gemeinsame Verantwortung in der privaten AWS-Zertifizierungsstelle

AWS Private CA arbeitet nach dem AWS-Modell der geteilten Verantwortung, bei dem klar zwischen dem, was AWS gehört, und dem, was dem Kunden gehört, unterschieden wird.

Zu den von AWS übernommenen Verantwortlichkeiten gehören die physische Sicherheit der Rechenzentren, in denen die KMS-HSMs zum Schutz der CA-Schlüssel gehostet werden, die Verfügbarkeit und Dauerhaftigkeit des AWS Private CA-Dienstes selbst, die FIPS 140-2 Level 3-Validierung der HSMs zum Schutz der KMS-verwalteten Schlüssel, die automatische Replikation der CA-Konfiguration und der Schlüssel über Verfügbarkeitszonen innerhalb einer Region hinweg, die Sicherheit der verwalteten OCSP-Responder-Infrastruktur sowie das Patchen und die Wartung der zugrunde liegenden Serviceinfrastruktur.

Zu den vom Kunden übernommenen Verantwortlichkeiten gehören Entscheidungen über die Gestaltung der CA-Hierarchie, die Konfiguration der IAM-Richtlinien (wer darf Zertifikate ausstellen, wer darf CAs verwalten), die Wahl des KMS-Schlüsseltyps (AWS-verwaltet oder kundenverwaltet), die Auswahl und Konfiguration der Zertifikatvorlage für jede CA, die Konfiguration des Widerrufs (OCSP-Aktivierung, Zugriff auf den CRL-S3-Bucket), die Konfiguration der Überwachung und Alarmierung für Zertifikatsereignisse, die Automatisierung der Zertifikatserneuerung, die Verteilung des privaten CA-Root-Zertifikats an alle Truststores der vertrauenden Parteien sowie die für Compliance-Programme erforderliche Dokumentation der Zertifikatsrichtlinie und der Erklärung zu Zertifizierungspraktiken.

Wie Verschlüsselungsberatung helfen kann

Encryption Consulting ist ein Beratungsunternehmen für angewandte Kryptografie und Cloud-Sicherheit mit Zertifizierungen nach ISO/IEC 27001:2022 und SOC 2. Wir unterstützen Organisationen bei der Konzeption, Implementierung und Verwaltung von AWS Private CA-Bereitstellungen – von der ersten Hierarchieplanung über die Automatisierung des Zertifikatslebenszyklus bis hin zur Erfassung von Compliance-Nachweisen.

• PKI als Dienstleistung: Für Organisationen, die eine verwaltete PKI ohne die operative Komplexität des eigenen Betriebs einer AWS Private CA wünschen, bietet Encryption Consulting die passende Lösung. PKI als Service Wir bieten eine vollständig verwaltete private Zertifizierungsstelle mit FIPS-validiertem HSM-Schlüsselschutz, Unterstützung bei der Root-CA-Zeremonie, CP/CPS-Dokumentation und 24/7-Überwachung. Die Integration in AWS-Workloads ist möglich, ohne Ihr Team mit dem CA-Betrieb zu belasten.
• CertSecure Manager (CLM): AWS Private CA stellt zwar die CA-Infrastruktur bereit, jedoch kein Lebenszyklusmanagement für die von ihr ausgestellten Zertifikate. (Encryption Consulting) CertSecure Manager Es bietet Zertifikatserkennung, Ablaufüberwachung, automatisierte Erneuerung über ACME und EST sowie eine einheitliche Zertifikatsverwaltung für AWS Private CA, Microsoft AD CS und andere Zertifizierungsstellen. Da das CA/B Forum SC-081v3 die Zertifikatsgültigkeit auf 47 Tage verkürzt, wird ein automatisiertes Zertifikatsmanagement unerlässlich.
• PKI-Dienstleistungen und Beratung: Wenn Sie eine CA-Hierarchie für AWS Private CA entwerfen, die Vor- und Nachteile von Private Cloud und Hybrid Cloud abwägen oder ein Zertifikatsrichtlinien- und CPS-Dokument für ein Compliance-Audit benötigen, ist Encryption Consulting der richtige Ansprechpartner. PKI-Dienste Beinhaltet CA-Hierarchie-Design, Schlüsselzeremonien-Moderation für hybride Bereitstellungen und CP/CPS-Entwicklung für jedes PKI-Konformitätsframework (NIST, WebTrust, ETSI).
• HSM als Dienstleistung: Für Hybridbereitstellungen, die eine lokale Stammzertifizierungsstelle erfordern, die durch ein dediziertes, FIPS-validiertes HSM unterstützt wird, bietet Encryption Consulting die passende Lösung. HSM als Service bietet die verwaltete HSM-Infrastruktur für Ihren Root-CA-Schlüssel ohne Investitionskosten für HSM-Hardware.
• CBOM Secure: Organisch gewachsene AWS Private CA-Bereitstellungen enthalten oft mehr Zertifizierungsstellen, Zertifikate und Schlüsseltypen, als Sicherheitsteams manuell verwalten können. Encryption Consulting CBOM Secure Erkennt und inventarisiert alle kryptografischen Assets in Ihrer AWS-Umgebung, einschließlich von AWS Private CA ausgestellter Zertifikate, KMS-Schlüssel und ACM-Zertifikate, und generiert eine kryptografische Stückliste (CBOM) im CycloneDX-Format für Compliance- und Auditzwecke.
• PQC-Bereitschaft: Das NIST finalisierte im August 2024 die Post-Quanten-Kryptographiestandards FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) und FIPS 205 (SLH-DSA). NIST IR 8547 deutet darauf hin, dass RSA und ECC für neue Anwendungsfälle um das Jahr 2030 als veraltet gelten werden. Wenn Ihre AWS Private CA-Hierarchie derzeit RSA- oder ECDSA-CA-Schlüssel verwendet, sollten Sie jetzt mit der Migrationsplanung beginnen. (Encryption Consulting) PQC-Bereitschaft Der Service bewertet Ihre AWS Private CA-Hierarchie anhand des Zeitplans für die Migration nach der Quantenmigration und entwirft den Übergangspfad für den Algorithmus.

Um Ihre Anforderungen an die Gestaltung Ihrer privaten AWS-Zertifizierungsstelle, die Automatisierung Ihres CLM-Systems oder die Einhaltung von Vorschriften zu besprechen, wenden Sie sich an Encryption Consulting.

Fazit

AWS Private CA beseitigt die Hardwarebeschaffung, den Platzbedarf im Rechenzentrum und die operative Komplexität des Betriebs einer privaten Zertifizierungsstelle und erhält gleichzeitig alle wichtigen Sicherheitskontrollen: Wahl des Schlüsselalgorithmus, Design der CA-Hierarchie, IAM-erzwungene Rollentrennung, KMS-gestützter Schlüsselschutz mit Kundenkontrolle und ein vollständiger CloudTrail-Audit-Trail für jeden Zertifikatsvorgang.

Die wichtigsten Entscheidungen, die darüber entscheiden, ob eine AWS Private CA-Bereitstellung sicher, kosteneffektiv und auditierbar ist, sind keine Standardeinstellungen: das Hierarchiemodell Private Cloud versus Hybrid Cloud, der KMS-Schlüsseltyp (AWS-verwaltet versus kundenverwaltet BYOK), der Betriebsmodus (Allgemein für 400 $/CA/Monat versus Kurzzeit für 50 $/CA/Monat für Zertifikate mit einer Gültigkeitsdauer von unter 7 Tagen), die Trennung der IAM-Rollen zwischen CA-Administratoren und Zertifikatsausstellern sowie die CLM-Automatisierungsschicht, die die Erneuerung übernimmt, wenn die Gültigkeitsdauer der Zertifikate auf 47 Tage verkürzt wird.

Organisationen, die von einer lokalen PKI zu einer privaten AWS-Zertifizierungsstelle migrieren, sollten dies als Chance zur PKI-Neugestaltung und nicht als einfache Migration betrachten. Das Hybrid-Cloud-Modell wahrt die Souveränität der Root-CA-Schlüssel und bietet gleichzeitig die Vorteile der Cloud für die Zertifikatsausstellung. BYOK mit kundenverwalteten KMS-Schlüsseln bietet einen unabhängigen Kill-Switch und eine von Auditoren überprüfbare Schlüsselherkunft. Der kurzlebige Zertifikatsmodus mit nur einem Achtel der CA-Betriebskosten ist die optimale Architektur für alle Anwendungsfälle mit häufigem mTLS- oder Workload-Identitätsmanagement.

Häufig gestellte Fragen

Was ist eine private AWS-Zertifizierungsstelle und wie unterscheidet sie sich vom AWS Certificate Manager (ACM)?

AWS Private CA (ehemals ACM Private CA) ist ein verwalteter privater Zertifizierungsstellendienst zur Ausstellung von privat vertrauenswürdigen X.509-Zertifikaten für interne Workloads. AWS Certificate Manager (ACM) stellt kostenlose öffentliche TLS-Zertifikate für die Verwendung mit ACM-integrierten AWS-Services bereit. ACM-Zertifikate können nicht exportiert werden; Private-CA-Zertifikate hingegen können zusammen mit ihrem privaten Schlüssel exportiert und beliebig verwendet werden. ACM-Zertifikate sind öffentlich vertrauenswürdig; Private-CA-Zertifikate werden nur von Systemen als vertrauenswürdig eingestuft, die Sie für die Verwaltung Ihrer Zertifizierungsstellenhierarchie konfiguriert haben.

Worin besteht der Unterschied zwischen Private-Cloud- und Hybrid-Cloud-Modellen in AWS Private CA?

Im Private-Cloud-Modell befinden sich sowohl die Stammzertifizierungsstellen als auch die untergeordneten Zertifizierungsstellen in AWS Private CA, die Schlüssel werden in AWS KMS verwaltet. Im Hybrid-Cloud-Modell befindet sich die Stammzertifizierungsstelle lokal in einem von Ihnen kontrollierten HSM, während sich nur die untergeordneten Zertifizierungsstellen in AWS Private CA befinden. Das Hybrid-Modell ermöglicht Ihnen die direkte Kontrolle über den Schlüssel der Stammzertifizierungsstelle; das Private-Cloud-Modell bietet vollständige Cloud-Automatisierung ohne lokale Infrastrukturanforderungen.

Wie viel kostet eine private AWS-Zertifizierungsstelle pro Monat?

AWS Private CA berechnet 400 US-Dollar pro CA und Monat im allgemeinen Modus und 50 US-Dollar pro CA und Monat im Modus für kurzlebige Zertifikate (Gültigkeit maximal 7 Tage). Die Zertifikatsausstellung ist gestaffelt: 0.75 US-Dollar pro Zertifikat für die ersten 1,000, 0.35 US-Dollar pro Zertifikat für 1,001 bis 10,000 und 0.001 US-Dollar pro Zertifikat über 10,000 pro Region und Monat für allgemeine CAs. Kurzlebige Zertifikate kosten pauschal 0.058 US-Dollar pro Zertifikat. OCSP kostet zusätzlich 0.06 US-Dollar pro Zertifikat und Monat bei Abfragen sowie 0.20 US-Dollar pro 100,000 Abfragen. AWS bietet eine 30-tägige kostenlose Testphase für den CA-Betrieb der ersten Private CA pro Konto und Region.

Unterstützt AWS Private CA BYOK (Bring Your Own Key)?

Ja. AWS Private CA verwendet AWS KMS zum Schutz von CA-Schlüsseln. Standardmäßig werden AWS-verwaltete KMS-Schlüssel verwendet. Sie können beim Erstellen der CA einen kundenseitig verwalteten KMS-Schlüssel (mit importiertem Schlüsselmaterial) angeben. Mit importiertem Schlüsselmaterial behalten Sie den Quellschlüssel und können ihn aus KMS löschen, um die Signierung neuer Zertifikate durch die CA sofort zu verhindern. Echtes HYOK (bei dem der CA-Schlüssel niemals in AWS gelangt) erfordert eine Hybrid-Cloud-Architektur mit einer lokalen Stammzertifizierungsstelle.

Welche IAM-Berechtigungen benötigt AWS Private CA?

CA-Administratoren benötigen die Berechtigungen `acm-pca:CreateCertificateAuthority`, `acm-pca:UpdateCertificateAuthority`, `acm-pca:DeleteCertificateAuthority` und `acm-pca:ImportCertificateAuthorityCertificate`. Zertifikatsaussteller benötigen die Berechtigungen `acm-pca:IssueCertificate`, `acm-pca:GetCertificate` und `acm-pca:RevokeCertificate`. Diese Rollen müssen getrennt sein: Kein einzelner Benutzer sollte sowohl die CA-Verwaltung als auch die Zertifikatsausstellungsberechtigung besitzen. Die kontoübergreifende Ausstellung erfordert eine ressourcenbasierte Richtlinie auf der privaten CA, die dem anfragenden Benutzer die Berechtigung `IssueCertificate` erteilt.

Welche Zertifikatstypen kann eine private AWS-Zertifizierungsstelle ausstellen?

Die private AWS-Zertifizierungsstelle kann X.509-Zertifikate für die TLS-Serverauthentifizierung, die TLS-Clientauthentifizierung (mTLS), die Codesignierung, den E-Mail-Schutz (S/MIME), die OCSP-Signierung und anwendungsspezifische Zwecke ausstellen. Sie unterstützt die Schlüsselalgorithmen RSA 2048, RSA 4096, ECDSA P-256 und ECDSA P-384. Zertifikatvorlagen erzwingen die zulässigen und erweiterten Schlüsselverwendungen für jeden Zertifikatstyp und verhindern so die Ausstellung von Zertifikatstypen, die nicht in der Vorlage definiert sind.