Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Entwickeln Sie Ihre Lösung für AWS Private CA
AWS Private CA bietet Ihnen die vollständige, cloudbasierte Kontrolle über die private PKI (Public Key Infrastructure) Ihres Unternehmens, die sich von einer Stammzertifizierungsstelle (CA) über untergeordnete CAs Zertifikate bis hin zu Endentitätszertifikaten erstreckt. Eine gründliche Planung ist unerlässlich für eine PKI, die sicher, wartbar, erweiterbar und auf die Anforderungen Ihrer Organisation abgestimmt ist. Dieser Abschnitt enthält Anweisungen zum Entwerfen einer CA-Hierarchie, zum Verwalten Ihrer privaten CA und der Lebenszyklen von privaten Endentitätszertifikaten und zum Anwenden von bewährten Methoden für die Sicherheit.
In diesem Abschnitt wird beschrieben, wie Sie sich auf AWS Private CA die Nutzung vorbereiten, bevor Sie eine private Zertifizierungsstelle (CA) einrichten. Außerdem wird die Option erklärt, Sperrunterstützung über das Online Certificate Status Protocol (OCSP) oder eine Zertifikatsperrliste (CRL) hinzuzufügen.
Darüber hinaus sollten Sie festlegen, ob Ihre Organisation es vorzieht, ihre privaten Root-CA-Anmeldeinformationen vor Ort zu hosten als mit. AWS In diesem Fall müssen Sie vor der Verwendung eine selbstverwaltete private PKI einrichten und sichern. AWS Private CA In diesem Szenario erstellen Sie dann eine untergeordnete Zertifizierungsstelle, die von einer übergeordneten Zertifizierungsstelle außerhalb von AWS Private CA unterstützt wird. AWS Private CA Weitere Informationen finden Sie unter [Installation eines untergeordneten Zertifizierungsstellenzertifikats, das von einer externen übergeordneten Zertifizierungsstelle signiert wurde](https://docs.aws.amazon.com/privateca/latest/userguide/PCACertInstall.html#InstallSubordinateExternal).
**Topics**
+ [Entwerfen Sie eine CA-Hierarchie](ca-hierarchy.md)
+ [Verwalten Sie den privaten CA-Lebenszyklus](ca-lifecycle.md)
+ [Planen Sie Ihre Methode zum Widerruf von AWS Private CA Zertifikaten](revocation-setup.md)
+ [AWS Private CA Verstehen Sie die CA-Modi](short-lived-certificates.md)
+ [Planen Sie für Resilienz in AWS Private CA](disaster-recovery-resilience.md)
# Entwerfen Sie eine CA-Hierarchie
Mit AWS Private CA können Sie eine Hierarchie von Zertifizierungsstellen mit bis zu fünf Ebenen erstellen. Die Stamm-CA im oberen Bereich einer Hierarchiestruktur kann eine beliebige Anzahl von Verzweigungen aufweisen. Die Stammzertifizierungsstelle kann in jeder Filiale bis zu vier untergeordnete CAs Ebenen haben. Sie können auch mehrere Hierarchien erstellen, jede mit einem eigenen Stamm.
Eine gut gestaltete CA-Hierarchie bietet folgende Vorteile:
+ Detaillierte Sicherheitskontrollen, die für die einzelnen CAs geeignet sind
+ Aufteilung von administrativen Aufgaben für besseren Lastausgleich und Sicherheit
+ Verwendung von CAs mit begrenztem, widerrufbarem Vertrauen für den täglichen Betrieb
+ Gültigkeitszeiträume und Zertifikatspfadbeschränkungen
Das folgende Diagramm veranschaulicht eine einfache CA-Hierarchie mit drei Ebenen.
![\[Diagramm einer einfachen CA-Hierarchie mit drei Ebenen.\]](http://docs.aws.amazon.com/de_de/privateca/latest/userguide/images/simple-ca-tree.png)
Jede Zertifizierungsstelle in der Struktur wird durch ein X.509 v3-Zertifikat mit Signaturberechtigung (symbolisiert durch das Symbol) unterstützt. pen-and-paper Das bedeutet, dass sie andere ihnen untergeordnete Zertifikate signieren können. CAs Wenn eine CA das Zertifikat einer untergeordneten CA signiert, verleiht sie dem signierten Zertifikat eine eingeschränkte, widerrufliche Autorität. Die Stamm-CA auf Ebene 1 signiert untergeordnete CA-Zertifikate auf Ebene 2. Diese CAs wiederum signieren Zertifikate für CAs Stufe 3, die von PKI-Administratoren (Public Key Infrastructure) verwendet werden, die Endzertifikate verwalten.
Sicherheit in einer CA-Hierarchie sollte so konfiguriert werden, dass sie im oberen Bereich der Struktur am stärksten ist. Diese Anordnung schützt das Stamm-CA-Zertifikat und seinen privaten Schlüssel. Die Stammzertifizierungsstelle verankert die Vertrauensstellung für alle untergeordneten Zertifikate CAs und die untergeordneten Entitätszertifikate. Während lokaler Schaden durch die Kompromittierung eines Endentitätszertifikats entstehen kann, zerstört die Kompromittierung des Stammes die Vertrauensstellung in der gesamten PKI. Stammzertifikate und untergeordnete Zertifikate auf hoher Ebene CAs werden nur selten verwendet (normalerweise zum Signieren anderer CA-Zertifikate). Folglich werden sie streng kontrolliert und geprüft, um ein geringeres Risiko von Kompromittierungen zu gewährleisten. Auf den unteren Ebenen der Hierarchie ist die Sicherheit weniger restriktiv. Dieser Ansatz ermöglicht die routinemäßigen Verwaltungsaufgaben beim Ausstellen und Widerrufen von Endentitätszertifikaten für Benutzer, Computer-Hosts und Softwaredienste.
**Anmerkung**
Die Verwendung einer Stamm-CA zum Signieren eines untergeordneten Zertifikats ist ein seltenes Ereignis, das nur unter einer Handvoll von Umständen auftritt:
Wenn die PKI erstellt wird
Wenn eine CA auf hoher Ebene ersetzt werden muss
Wenn eine Zertifikatssperrliste (CRL) oder ein OCSP-Responder (Online Certificate Status Protocol) konfiguriert werden muss
Root- und andere CAs High-Level-Zertifikate erfordern hochsichere Betriebsprozesse und Zugriffskontrollprotokolle.
**Topics**
+ [Validieren Sie die Zertifikate der Endunternehmen](#end-entity-validation)
+ [Planen Sie die Struktur einer CA-Hierarchie](#ca-layers)
+ [Legen Sie Längenbeschränkungen für den Zertifizierungspfad fest](#length-constraints)
## Validieren Sie die Zertifikate der Endunternehmen
Endzertifikate erhalten ihr Vertrauen aus einem Zertifizierungspfad, der über die untergeordnete Zertifizierungsstelle zurück CAs zu einer Stammzertifizierungsstelle führt. Wenn einem Webbrowser oder einem anderen Client ein Endentitätszertifikat präsentiert wird, versucht er, eine Vertrauenskette zu erstellen. Beispielsweise überprüft er etwa, ob der *definierte Name (Distinguished Name) des Ausstellers* und der *definierte Name des Subjekts* des Zertifikats mit den entsprechenden Feldern des ausstellenden CA-Zertifikats übereinstimmen. Der Abgleich würde dann auf jeder aufeinanderfolgenden Ebene in der Hierarchie nach oben fortgesetzt, bis der Client eine vertrauenswürdige Stamm-CA erreicht, die in seinem Trust Store (Vertrauensspeicher) enthalten ist.
Der Trust Store ist eine vertrauenswürdige Bibliothek, die der Browser oder CAs das Betriebssystem enthält. Bei einer privaten PKI muss die IT Ihrer Organisation sicherstellen, dass jeder Browser oder jedes System die private Stamm-CA vorab dem Vertrauensspeicher hinzugefügt hat. Andernfalls kann der Zertifizierungspfad nicht validiert werden, was zu Client-Fehlern führt.
Das nächste Diagramm zeigt den Validierungspfad, dem ein Browser folgt, wenn ein X.509-Endentitätszertifikat vorliegt. Beachten Sie, dass das Endentitätszertifikat keine Signaturautorität besitzt und nur dazu dient, die Entität zu authentifizieren, die es besitzt.
![\[Validierungsprüfung durch einen Webbrowser.\]](http://docs.aws.amazon.com/de_de/privateca/latest/userguide/images/chain-of-trust.png)
Der Browser überprüft das Endentitätszertifikat. Der Browser stellt fest, dass das Zertifikat eine Signatur von der untergeordneten CA (Ebene 3) als vertrauenswürdige Anmeldeinformationen anbietet. Die Zertifikate für das untergeordnete Unternehmen CAs müssen in derselben PEM-Datei enthalten sein. Alternativ können sie sich auch in einer separaten Datei befinden, die die Zertifikate enthält, aus denen die Vertrauenskette besteht. Sind diese gefunden, überprüft der Browser das Zertifikat der untergeordneten CA (Ebene 3) und stellt fest, dass es eine Signatur von der untergeordneten CA (Ebene 2) bietet. Die untergeordnete CA (Ebene 2) bietet wiederum eine Signatur von der Stamm-CA (Ebene 1) als vertrauenswürdige Anmeldeinformationen. Wenn der Browser eine Kopie des privaten Stamm-CA-Zertifikats findet, das in seinem Vertrauensspeicher vorinstalliert ist, validiert er das Endentitätszertifikat als vertrauenswürdig.
In der Regel überprüft der Browser auch jedes Zertifikat anhand einer Zertifikatsperrliste (CRL). Ein abgelaufenes, gesperrtes oder falsch konfiguriertes Zertifikat wird abgelehnt und die Validierung schlägt fehl.
## Planen Sie die Struktur einer CA-Hierarchie
Im Allgemeinen sollte Ihre CA-Hierarchie die Struktur Ihrer Organisation widerspiegeln. Streben Sie eine *Pfadlänge* (d. h. die Anzahl der CA-Ebenen) an, die nicht größer ist als für die Delegierung von Verwaltungs- und Sicherheitsrollen erforderlich. Das Hinzufügen einer CA zur Hierarchie bedeutet, die Anzahl der Zertifikate im Zertifizierungspfad zu erhöhen, was die Validierungsdauer erhöht. Wenn Sie die Pfadlänge auf ein Minimum beschränken, wird auch die Anzahl der Zertifikate reduziert, die bei der Validierung eines Endzertifikats vom Server an den Client gesendet werden.
Theoretisch kann eine Stammzertifizierungsstelle, die keinen [pathLenConstraint](PcaTerms.md#terms-pathlength)Parameter hat, eine unbegrenzte Anzahl von untergeordneten Zertifizierungsstellen autorisieren. CAs Eine untergeordnete Zertifizierungsstelle kann so viele untergeordnete Zertifizierungsstellen haben, CAs wie es ihre interne Konfiguration zulässt. AWS Private CA verwaltete Hierarchien unterstützen CA-Zertifizierungspfade mit einer Tiefe von bis zu fünf Ebenen.
Gut gestaltete CA-Strukturen haben mehrere Vorteile:
+ Separate Verwaltungskontrollen für verschiedene Organisationseinheiten
+ Die Fähigkeit, den Zugriff an untergeordnete Personen zu delegieren CAs
+ Eine hierarchische Struktur, die höhere Ebenen durch zusätzliche Sicherheitskontrollen CAs schützt
Zwei häufige CA-Strukturen erfüllen all dies:
+ **Zwei CA-Ebenen: Stamm-CA und untergeordnete CA**
Dies ist die einfachste CA-Struktur, die separate Verwaltungs-, Kontroll- und Sicherheitsrichtlinien für die Stamm-CA und eine untergeordnete CA ermöglicht. Sie können restriktive Kontrollen und Richtlinien für Ihre Stamm-CA aufrechterhalten und gleichzeitig der untergeordneten CA weitreichenderen Zugriff gewähren. Letzteres wird für die Massenausgabe von Endentitätszertifikaten verwendet.
+ **Drei CA-Ebenen: Stamm-CA und zwei Ebenen untergeordneter CAs**
Ähnlich wie oben fügt diese Struktur eine zusätzliche CA-Ebene hinzu, um die Stamm-CA weiter von CA-Operationen auf niedriger Ebene zu trennen. Die mittlere CA-Schicht wird nur zum Signieren untergeordneter Stellen verwendet, die für CAs die Ausstellung von Endzertifikaten zuständig sind.
Zu den selteneren CA-Strukturen gehören die folgenden:
+ **Vier oder mehr CA-Ebenen**
Obwohl weniger häufig als Hierarchien mit drei Ebenen, sind CA-Hierarchien mit vier oder mehr Ebenen möglich und unter Umständen erforderlich, um die Delegierung administrativer Aufgaben zu ermöglichen.
+ **Eine CA-Ebene: nur Stamm-CA**
Diese Struktur wird häufig für die Entwicklung und das Durchführen von Tests verwendet, wenn keine vollständige Vertrauenskette erforderlich ist. Ihre Verwendung in der Produktion ist untypisch. Darüber hinaus verstößt sie gegen die bewährte Methode, separate Sicherheitsrichtlinien für die Stammzertifizierungsstelle und die Zertifizierungsstellen, die Endzertifikate ausstellen CAs , aufrechtzuerhalten.
Wenn Sie jedoch bereits Zertifikate direkt von einer Stammzertifizierungsstelle ausstellen, können Sie zu dieser migrieren. AWS Private CA Dies bietet Sicherheits- und Kontrollvorteile gegenüber der Verwendung einer Root-CA, die mit [OpenSSL](https://www.openssl.org/) oder anderer Software verwaltet wird.
### Beispiel für eine private PKI für einen Hersteller
In diesem Beispiel stellt ein hypothetisches Technologieunternehmen zwei IoT-Produkte (Internet of Things) her, eine intelligente Glühbirne und einen intelligenten Toaster. Während der Produktion wird für jedes Gerät ein Endentitätszertifikat ausgestellt, damit es sicher über das Internet mit dem Hersteller kommunizieren kann. Die PKI des Unternehmens sichert auch seine Computerinfrastruktur, einschließlich der internen Website und verschiedener selbst gehosteter Computerdienste, die Finanz- und Geschäftsabläufe ausführen.
Folglich ist die CA-Hierarchie eng an diesen administrativen und operativen Aspekten des Geschäfts ausgerichtet.
![\[Diagramm einer komplexeren CA-Hierarchie.\]](http://docs.aws.amazon.com/de_de/privateca/latest/userguide/images/multilevel-ca-tree.png)
Diese Hierarchie enthält drei Stamm-CAs, eine für interne Vorgänge und zwei für externe Vorgänge (eine Stamm-CA für jede Produktlinie). Es zeigt auch mehrere Zertifizierungspfade mit zwei Zertifizierungsstufen für interne Abläufe und drei Stufen für externe Abläufe.
Die Verwendung getrennter Stamm CAs - und zusätzlicher untergeordneter CA-Ebenen für externe Operationen ist eine Designentscheidung, die den Geschäfts- und Sicherheitsanforderungen gerecht wird. Mit mehreren CA-Strukturen ist die PKI zukunftssicher im Fall von Unternehmensumstrukturierungen, Veräußerungen oder Akquisitionen. Wenn Änderungen auftreten, kann eine gesamte CA-Stammhierarchie mit der Abteilung, die sie sichert, ordnungsgemäß bewegt werden. Und da es zwei Ebenen untergeordneter Zertifizierungsstellen gibt, CAs sind die Stammzertifizierungsstellen weitgehend von der Ebene 3 isoliert, die für CAs die Massensignierung der Zertifikate für Tausende oder Millionen von hergestellten Produkten zuständig ist.
Auf der internen Seite vervollständigen Internet- und interne Computervorgänge des Unternehmens eine Hierarchie mit zwei Ebenen. Diese Ebenen ermöglichen es Webadministratoren und Betriebsingenieuren, die Zertifikatausstellung unabhängig für ihre eigenen Geschäftsdomänen zu verwalten. Die Aufteilung der PKI in verschiedene funktionale Domänen ist eine bewährte Methode im Bereich Sicherheit und schützt sie vor einer Kompromittierung, die sich auf die jeweils andere auswirken könnte. Webadministratoren stellen Endentitätszertifikate zur Verwendung durch Webbrowser im gesamten Unternehmen aus und authentifizieren und verschlüsseln so die Kommunikation auf der internen Website. Betriebsingenieure stellen Endentitätszertifikate aus, die Rechenzentrums-Hosts und Computerdienste gegenseitig authentifizieren. Dieses System trägt dazu bei, vertrauliche Daten zu schützen, indem es sie im LAN verschlüsselt.
## Legen Sie Längenbeschränkungen für den Zertifizierungspfad fest
Die Struktur einer CA-Hierarchie wird durch die *Erweiterung der Basiseinschränkungen* definiert und erzwungen, die jedes Zertifikat enthält. Die Erweiterung definiert zwei Einschränkungen:
+ `cA`— Ob das Zertifikat eine Zertifizierungsstelle definiert. Wenn dieser Wert *false* lautet (der Standardwert), ist das Zertifikat ein Endentitätszertifikat.
+ `pathLenConstraint`— Die maximale Anzahl untergeordneter Personen CAs , die in einer gültigen Vertrauenskette existieren können. Das Zertifikat der Endeinheit wird nicht gezählt, da es sich nicht um ein CA-Zertifikat handelt.
Ein Stamm-CA-Zertifikat erfordert maximale Flexibilität und enthält keine Pfadlängenbeschränkung. Dadurch kann der Stamm einen Zertifizierungspfad beliebiger Länge definieren.
**Anmerkung**
AWS Private CA begrenzt den Zertifizierungspfad auf fünf Stufen.
Untergeordnete Elemente CAs haben `pathLenConstraint` Werte, die gleich oder größer als Null sind, abhängig von der Position in der Hierarchie, der Platzierung und den gewünschten Funktionen. In einer Hierarchie mit drei CAs ist beispielsweise keine Pfadbeschränkung für die Stammzertifizierungsstelle angegeben. Die erste untergeordnete Zertifizierungsstelle hat eine Pfadlänge von 1 und kann daher eine untergeordnete CAs Zertifizierungsstelle signieren. Jedes dieser untergeordneten CAs Elemente muss unbedingt den `pathLenConstraint` Wert Null haben. Dies bedeutet, dass sie Endentitätszertifikate signieren, jedoch keine zusätzlichen CA-Zertifikate ausstellen können. Die Beschränkung der Fähigkeit, Neues zu schaffen, CAs ist eine wichtige Sicherheitskontrolle.
Das folgende Diagramm veranschaulicht diese Verbreitung von eingeschränkter Autorität in der Hierarchie.
![\[Diagramm einer einfachen CA-Hierarchie mit drei Ebenen.\]](http://docs.aws.amazon.com/de_de/privateca/latest/userguide/images/path-length.png)
In dieser Hierarchie mit vier Ebenen ist die Stamm-CA nicht eingeschränkt (wie immer). Die erste untergeordnete Zertifizierungsstelle hat jedoch einen `pathLenConstraint` Wert von 2, wodurch ihr untergeordnetes Objekt daran CAs gehindert wird, mehr als zwei Stufen tiefer vorzudringen. Folglich muss der Einschränkungswert für einen gültigen Zertifizierungspfad in den nächsten beiden Ebenen auf Null verringert werden. Wenn ein Webbrowser ein Endentitätszertifikat aus diesem Zweig vorfindet, das eine Pfadlänge größer als vier hat, schlägt die Validierung fehl. Ein solches Zertifikat könnte auf eine versehentlich erstellte CA, eine falsch konfigurierte CA oder eine nicht autorisierte Ausstellung zurückzuführen sein.
### Verwalten Sie die Pfadlänge mit Vorlagen
AWS Private CA stellt Vorlagen für die Ausstellung von Stamm-, untergeordneten und Endentitätszertifikaten bereit. Diese Vorlagen fassen bewährte Methoden für die grundlegenden Einschränkungswerte, einschließlich der Pfadlänge, zusammen. Die Vorlagen umfassen die folgenden:
+ Root /V1 CACertificate
+ Untergeordnet \$1 0/V1 CACertificate PathLen
+ Untergeordnet \$1 1/V1 CACertificate PathLen
+ Untergeordnet \$1 2/V1 CACertificate PathLen
+ Untergeordnet \$1 3/V1 CACertificate PathLen
+ EndEntityCertificate/V1
Die `IssueCertificate`-API gibt einen Fehler zurück, wenn Sie versuchen, eine CA mit einer Pfadlänge zu erstellen, die größer oder gleich der Pfadlänge des ausstellenden CA-Zertifikats ist.
Weitere Informationen zu Zertifikatvorlagen finden Sie unter [Verwenden Sie Zertifikatsvorlagen AWS Private CA](UsingTemplates.md).
### Automatisieren Sie die Einrichtung der CA-Hierarchie mit AWS CloudFormation
Wenn Sie sich für ein Design für Ihre CA-Hierarchie entschieden haben, können Sie es testen und mithilfe einer AWS CloudFormation Vorlage in Produktion nehmen. Ein Beispiel für eine solche Vorlage finden Sie unter [Deklarieren einer privaten CA-Hierarchie](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-acmpca-certificateauthority.html#aws-resource-acmpca-certificateauthority--examples) im *CloudFormation -Benutzerhandbuch*.
# Verwalten Sie den privaten CA-Lebenszyklus
CA-Zertifikate haben eine feste Lebensdauer bzw. einen festen Gültigkeitszeitraum. Wenn ein CA-Zertifikat abläuft, werden alle Zertifikate, die direkt oder indirekt von einer CAs untergeordneten Stelle in der CA-Hierarchie ausgestellt wurden, ungültig. Sie können den Ablauf von CA-Zertifikaten vermeiden, indem Sie im Voraus planen.
## Wählen Sie Gültigkeitszeiträume
Der Gültigkeitszeitraum eines X.509-Zertifikats ist ein erforderliches grundlegendes Zertifikatfeld. Er bestimmt den Zeitraum, in dem die ausstellende CA bescheinigt, dass das Zertifikat vertrauenswürdig ist, mit Ausnahme einer Sperre. (Ein Stammzertifikat, das selbst signiert wird, bescheinigt seinen eigenen Gültigkeitszeitraum.)
AWS Private CA und AWS Certificate Manager unterstützen Sie bei der Konfiguration der Gültigkeitszeiträume von Zertifikaten, wobei die folgenden Einschränkungen gelten:
+ Ein von verwaltetes Zertifikat AWS Private CA muss eine Gültigkeitsdauer haben, die kürzer oder gleich der Gültigkeitsdauer der Zertifizierungsstelle ist, die es ausgestellt hat. Mit anderen Worten, untergeordnete Zertifikate CAs und Endentitätszertifikate können ihre übergeordneten Zertifikate nicht überdauern. Der Versuch, die `IssueCertificate`-API zum Ausstellen eines CA-Zertifikats mit einem Gültigkeitszeitraum größer oder gleich der CA der übergeordneten CA zu verwenden, schlägt fehl.
+ Zertifikate, die von ausgestellt und verwaltet werden AWS Certificate Manager (diejenigen, für die ACM den privaten Schlüssel generiert), haben eine Gültigkeitsdauer von 13 Monaten (395 Tagen). ACM verwaltet den Verlängerungsprozess für diese Zertifikate. Wenn Sie Zertifikate direkt AWS Private CA ausstellen, können Sie einen beliebigen Gültigkeitszeitraum wählen.
Das folgende Diagramm zeigt eine typische Konfiguration von verschachtelten Gültigkeitszeiträumen. Das Stammzertifikat hat die längste Lebensdauer, Endzertifikate sind relativ kurzlebig, und untergeordnete Zertifikate liegen CAs zwischen diesen Extremen.
![\[Gültigkeitszeiträume untergeordneter CAs müssen innerhalb der Gültigkeitszeiträume ihrer übergeordneten CAs liegen.\]](http://docs.aws.amazon.com/de_de/privateca/latest/userguide/images/validity.png)
Bestimmen Sie beim Planen der CA-Hierarchie die optimale Lebensdauer Ihrer CA-Zertifikate. Arbeiten Sie ab der gewünschten Lebensdauer der Endentitätszertifikate, die Sie ausstellen möchten, rückwärts.
**Endentitätszertifikate**
Endentitätszertifikate sollten über einen dem Anwendungsfall entsprechenden Gültigkeitszeitraum verfügen. Eine kurze Lebensdauer minimiert das Risiko für ein Zertifikat in dem Fall, dass sein privater Schlüssel verloren geht oder gestohlen wird. Kurze Lebensdauern bedeuten jedoch häufige Erneuerungen. Wenn ein abgelaufenes Zertifikat nicht erneuert wird, kann es zu Ausfallzeiten kommen.
Die verteilte Verwendung von Endentitätszertifikaten kann auch logistische Probleme darstellen, wenn es zu einer Sicherheitsverletzung kommt. In Ihrer Planung sollten Erneuerungs- und Verteilungszertifikate, das Sperren von kompromittierten Zertifikaten und die Schnelligkeit der Verbreitung von Sperren auf Clients, die auf die Zertifikate angewiesen sind, berücksichtigt werden.
Die Standardgültigkeitsdauer für ein über ACM ausgestelltes Endzertifizierungszertifikat beträgt 13 Monate (395 Tage). In können Sie die `IssueCertificate` API verwenden AWS Private CA, um einen beliebigen Gültigkeitszeitraum anzuwenden, sofern dieser kürzer ist als der der ausstellenden Zertifizierungsstelle.
**Untergeordnete CA-Zertifikate**
Untergeordnete CA-Zertifikate sollten wesentlich längere Gültigkeitszeiträume haben als die von ihnen ausgestellten Zertifikate. Ein guter Bereich für die Gültigkeit eines CA-Zertifikats ist das zwei- bis fünffache des Zeitraums eines untergeordneten CA-Zertifikats oder eines Endentitätszertifikats. Angenommen, Sie haben eine CA-Hierarchie mit zwei Ebenen (Stamm-CA und eine untergeordnete CA). Wenn Sie Endentitätszertifikate mit einer Laufzeit von einem Jahr ausstellen möchten, können Sie die Lebensdauer der untergeordneten ausstellenden CA auf drei Jahre konfigurieren. Dies ist die Standardgültigkeitsdauer für ein untergeordnetes CA-Zertifikat in AWS Private CA. Untergeordnete CA-Zertifikate können geändert werden, ohne das Stamm-CA-Zertifikat zu ersetzen.
**Stammzertifikate**
Änderungen an einem Stamm-CA-Zertifikat wirken sich auf die gesamte PKI (Public Key-Infrastruktur) aus und erfordern, dass Sie alle abhängigen Client-Betriebssystem- und Browser-Vertrauensspeicher aktualisieren müssen. Um die Auswirkungen auf die Betriebsabläufe zu minimieren, sollten Sie für das Stammzertifikat einen langen Gültigkeitszeitraum wählen. Die AWS Private CA Standardeinstellung für Stammzertifikate beträgt zehn Jahre.
## Die CA-Nachfolge verwalten
Sie haben zwei Möglichkeiten, die CA-Abfolge zu verwalten: Ersetzen Sie die alte CA oder stellen Sie die CA erneut mit einem neuen Gültigkeitszeitraum aus.
### Ersetzen Sie eine alte CA
Um eine alte CA zu ersetzen, erstellen Sie eine neue CA und verketten Sie sie mit derselben übergeordneten CA. Anschließend stellen Sie Zertifikate von der neuen CA aus.
Zertifikate, die von der neuen CA ausgestellt wurden, verfügen über eine neue CA-Kette. Sobald die neue CA eingerichtet ist, können Sie die alte CA deaktivieren, um zu verhindern, dass sie neue Zertifikate ausstellt. Wenn die alte Zertifizierungsstelle deaktiviert ist, unterstützt sie den Widerruf alter Zertifikate, die von der Zertifizierungsstelle ausgestellt wurden. Falls sie entsprechend konfiguriert ist, validiert sie weiterhin Zertifikate mithilfe von and/or OCSP-Zertifikatssperrlisten (CRLs). Wenn das letzte von der alten CA ausgestellte Zertifikat abläuft, können Sie die alte CA löschen. Sie können einen Auditbericht für alle von der CA ausgestellten Zertifikate generieren, um zu bestätigen, dass alle ausgestellten Zertifikate abgelaufen sind. Wenn die alte Zertifizierungsstelle über eine untergeordnete Zertifizierungsstelle verfügt CAs, müssen Sie diese ebenfalls ersetzen, da die untergeordnete Zertifizierungsstelle zur gleichen Zeit oder vor ihrer übergeordneten Zertifizierungsstelle CAs abläuft. Ersetzen Sie zunächst die höchste CA in der Hierarchie, die ersetzt werden muss. Erstellen Sie dann auf jeder nachfolgenden untergeordneten Ebene eine neue untergeordnete CAs Ersatzinstanz.
AWS empfiehlt, dass Sie bei Bedarf eine Generierungs-ID der Zertifizierungsstelle in die Namen von CAs aufnehmen. Nehmen wir beispielsweise an, dass Sie die CA der ersten Generation „Corporate Root CA“ nennen. Wenn Sie die Zertifizierungsstelle der zweiten Generation erstellen, nennen Sie sie „Corporate Root CA G2". Diese einfache Benennungskonvention kann dazu beitragen, Verwechslungen zu vermeiden, wenn beide CAs noch nicht abgelaufen sind.
Diese Methode der CA-Abfolge wird bevorzugt, da dabei der private Schlüssel der CA rotiert. Das Rotieren des privaten Schlüssels ist eine bewährte Methode für CA-Schlüssel. Die Rotationshäufigkeit sollte proportional zur Häufigkeit der Schlüsselnutzung sein: Zertifikate CAs, die mehr ausstellen, sollten häufiger rotiert werden.
**Anmerkung**
Private Zertifikate, die über ACM ausgestellt wurden, können nicht erneuert werden, wenn Sie die CA austauschen. Wenn Sie ACM für die Ausstellung und Verlängerung verwenden, müssen Sie das CA-Zertifikat erneut ausstellen, um die Lebensdauer der Zertifizierungsstelle zu verlängern.
### Eine alte CA erneut ausstellen
Wenn sich eine CA dem Ablauf nähert, besteht eine alternative Methode zur Verlängerung ihrer Lebensdauer darin, das CA-Zertifikat mit einem neuen Ablaufdatum erneut auszustellen. Bei der Neuausstellung bleiben alle CA-Metadaten erhalten und die vorhandenen privaten und öffentlichen Schlüssel werden beibehalten. In diesem Szenario bleiben die bestehende Zertifikatskette und die noch nicht abgelaufenen, von der Zertifizierungsstelle ausgestellten Endzertifikate gültig, bis sie ablaufen. Die Ausstellung neuer Zertifikate kann auch ohne Unterbrechung fortgesetzt werden. Um eine Zertifizierungsstelle mit einem neu ausgestellten Zertifikat zu aktualisieren, folgen Sie den üblichen Installationsverfahren, die unter beschrieben sind. [Installation des CA-Zertifikats](PCACertInstall.md)
**Anmerkung**
Wir empfehlen, eine auslaufende Zertifizierungsstelle zu ersetzen, anstatt ihr Zertifikat erneut auszustellen, da die Umstellung auf ein neues key pair Sicherheitsvorteile bietet.
## Widerrufen Sie eine CA
Sie widerrufen eine CA, indem Sie ihr zugrundeliegendes Zertifikat widerrufen. Dadurch werden auch effektiv alle von der CA ausgestellten Zertifikate gesperrt. Sperrinformationen werden über [OCSP oder eine CRL](revocation-setup.md) an die Clients verteilt. Sie sollten ein CA-Zertifikat nur dann widerrufen, wenn Sie alle von der Endeinheit ausgestellten Zertifikate und untergeordneten Zertifizierungsstellenzertifikate widerrufen möchten.
# Planen Sie Ihre Methode zum Widerruf von AWS Private CA Zertifikaten
Bei der Planung Ihrer privaten PKI sollten Sie überlegen AWS Private CA, wie Sie mit Situationen umgehen sollen, in denen Endgeräte einem ausgestellten Zertifikat nicht mehr vertrauen sollen, z. B. wenn der private Schlüssel eines Endpunkts offengelegt wird. Die gängigen Lösungsansätze für dieses Problem bestehen darin, kurzlebige Zertifikate zu verwenden oder den Widerruf von Zertifikaten zu konfigurieren. Kurzlebige Zertifikate laufen in einem so kurzen Zeitraum (in Stunden oder Tagen) ab, dass ein Widerruf keinen Sinn macht. Das Zertifikat wird in etwa der gleichen Zeit ungültig, die benötigt wird, um einen Endpunkt über den Widerruf zu benachrichtigen. In diesem Abschnitt werden die Widerrufsoptionen für AWS Private CA Kunden beschrieben, einschließlich Konfiguration und bewährten Methoden.
Kunden, die nach einer Sperrmethode suchen, können zwischen Online Certificate Status Protocol (OCSP), Zertifikatssperrlisten (CRLs) oder beidem wählen.
**Anmerkung**
Wenn Sie Ihre Zertifizierungsstelle erstellen, ohne den Widerruf zu konfigurieren, können Sie sie jederzeit später konfigurieren. Weitere Informationen finden Sie unter [Aktualisieren Sie eine private Zertifizierungsstelle in AWS Private Certificate Authority](PCAUpdateCA.md).
+ **Online Certificate Status Protocol (OCSP)**
AWS Private CA bietet eine vollständig verwaltete OCSP-Lösung, mit der Endgeräte darüber informiert werden, dass Zertifikate gesperrt wurden, ohne dass Kunden die Infrastruktur selbst betreiben müssen. Kunden können OCSP für neue oder bestehende Geräte CAs mit einem einzigen Vorgang über die AWS Private CA Konsole, die API, die CLI oder über CloudFormation die Konsole aktivieren. Während CRLs OCSP-Speicher- und Verarbeitungsanforderungen auf dem Endgerät gespeichert und verarbeitet werden und veralten können, werden OCSP-Speicher- und Verarbeitungsanforderungen synchron im Responder-Backend behandelt.
Wenn Sie OCSP für eine Zertifizierungsstelle aktivieren, AWS Private CA wird die URL des OCSP-Responders in die AIA-Erweiterung (*Authority Information Access*) jedes neu ausgestellten Zertifikats aufgenommen. Die Erweiterung ermöglicht es Clients wie Webbrowsern, den Responder abzufragen und festzustellen, ob ein Zertifikat der Endeinheit oder einer untergeordneten Zertifizierungsstelle vertrauenswürdig ist. Der Responder gibt eine Statusmeldung zurück, die kryptografisch signiert ist, um ihre Authentizität sicherzustellen.
[Der AWS Private CA OCSP-Responder entspricht RFC 5019.](https://datatracker.ietf.org/doc/html/rfc5019)
**Überlegungen zu OCSP**
+ OCSP-Statusmeldungen werden mit demselben Signaturalgorithmus signiert, für den die ausstellende Zertifizierungsstelle konfiguriert wurde. CAs Die in der AWS Private CA Konsole erstellten Dateien verwenden standardmäßig den SHA256 WITRSA-Signaturalgorithmus. Andere unterstützte Algorithmen finden Sie in der [CertificateAuthorityConfiguration](https://docs.aws.amazon.com/privateca/latest/APIReference/API_CertificateAuthorityConfiguration.html)API-Dokumentation.
+ [APIPassthrough und CSRPassthrough](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html#template-varieties) Zertifikatsvorlagen funktionieren nicht mit der AIA-Erweiterung, wenn der OCSP-Responder aktiviert ist.
+ Der Endpunkt des verwalteten OCSP-Dienstes ist über das öffentliche Internet zugänglich. Kunden, die OCSP nutzen, aber keinen öffentlichen Endpunkt bevorzugen, müssen ihre eigene OCSP-Infrastruktur betreiben.
+ **Sperrlisten für Zertifikate () CRLs**
Eine Zertifikatssperrliste (Certificate Revocation List, CRL) ist eine Datei, die eine Liste von Zertifikaten enthält, die vor ihrem geplanten Ablaufdatum gesperrt wurden. Die CRL enthält eine Liste von Zertifikaten, denen nicht mehr vertraut werden sollte, den Grund für den Widerruf und andere relevante Informationen.
Wenn Sie Ihre Zertifizierungsstelle (CA) konfigurieren, können Sie wählen, ob eine vollständige oder partitionierte CRL AWS Private CA erstellt werden soll. Ihre Wahl bestimmt die maximale Anzahl von Zertifikaten, die die Zertifizierungsstelle ausstellen und widerrufen kann. Weitere Informationen finden Sie unter [AWS Private CA -Kontingente](https://docs.aws.amazon.com/general/latest/gr/pca.html#limits_pca).
**Überlegungen zur CRL**
+ Überlegungen zu Speicher und Bandbreite: Aufgrund der lokalen Download- und Verarbeitungsanforderungen ist mehr Speicher CRLs erforderlich als bei OCSP. CRLsKönnte jedoch die Netzwerkbandbreite im Vergleich zu OCSP reduzieren, indem Sperrlisten zwischengespeichert werden, anstatt den Status pro Verbindung zu überprüfen. Bei Geräten mit beschränktem Speicherplatz, wie z. B. bestimmten IoT-Geräten, sollten Sie die Verwendung partitionierter Geräte in Betracht ziehen. CRLs
+ Änderung des CRL-Typs: Wenn Sie von einer vollständigen zu einer partitionierten CRL wechseln, werden bei Bedarf neue Partitionen AWS Private CA erstellt und allen Partitionen, einschließlich der ursprünglichen, die IDP-Erweiterung hinzugefügt. CRLs Der Wechsel von partitioniert zu vollständig aktualisiert nur eine einzige CRL und verhindert den future Widerruf von Zertifikaten, die mit früheren Partitionen verknüpft sind.
**Anmerkung**
Sowohl bei OCSP als auch bei der CRLs Statusänderung kommt es zu einer gewissen Verzögerung zwischen dem Widerruf und der Verfügbarkeit der Statusänderung.
Bei OCSP-Antworten kann es bis zu 60 Minuten dauern, bis der neue Status angezeigt wird, wenn Sie ein Zertifikat widerrufen. Im Allgemeinen unterstützt OCSP tendenziell eine schnellere Verteilung von Sperrinformationen, da OCSP-Antworten, im Gegensatz zu CRLs denen, die von Clients tagelang zwischengespeichert werden können, in der Regel nicht von Clients zwischengespeichert werden.
Eine Zertifikatssperrliste wird in der Regel etwa 30 Minuten nach Widerrufen eines Zertifikats aktualisiert. Falls eine CRL-Aktualisierung aus irgendeinem Grund fehlschlägt, werden alle 15 Minuten weitere AWS Private CA Versuche unternommen.
## Allgemeine Anforderungen für Sperrkonfigurationen
Die folgenden Anforderungen gelten für alle Sperrkonfigurationen.
+ Eine Konfiguration zur Deaktivierung CRLs oder OCSP darf nur den `Enabled=False` Parameter enthalten und schlägt fehl, wenn andere Parameter wie `CustomCname` oder enthalten `ExpirationInDays` sind.
+ In einer CRL-Konfiguration muss der `S3BucketName` Parameter den [Benennungsregeln von Amazon Simple Storage Service für Buckets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucketnamingrules.html) entsprechen.
+ Eine Konfiguration, die einen benutzerdefinierten Canonical Name (CNAME) -Parameter für CRLs oder OCSP enthält, muss den [RFC7230](https://www.ietf.org/rfc/rfc7230.txt)Beschränkungen für die Verwendung von Sonderzeichen in einem CNAME entsprechen.
+ In einer CRL- oder OCSP-Konfiguration darf der Wert von CNAME kein Protokollpräfix wie „http://“ oder „https://“ enthalten.
**Topics**
+ [Allgemeine Anforderungen für Sperrkonfigurationen](#revocation-requirements)
+ [Richten Sie eine CRL ein für AWS Private CA](crl-planning.md)
+ [Passen Sie die OCSP-URL an für AWS Private CA](ocsp-customize.md)
# Richten Sie eine CRL ein für AWS Private CA
Bevor Sie im Rahmen der [Erstellung der Zertifizierungsstelle eine Zertifikatssperrliste (CRL) konfigurieren können](create-CA.md), müssen Sie möglicherweise vorher einige Einstellungen vornehmen. In diesem Abschnitt werden die Voraussetzungen und Optionen erläutert, mit denen Sie vertraut sein sollten, bevor Sie eine Zertifizierungsstelle mit angehängter CRL erstellen.
Informationen zur Verwendung des Online Certificate Status Protocol (OCSP) als Alternative oder Ergänzung zu einer CRL finden Sie unter und. [](create-CA.md#PcaCreateRevocation) [Passen Sie die OCSP-URL an für AWS Private CA](ocsp-customize.md)
**Topics**
+ [CRL-Typen](#crl-type)
+ [CRL-Struktur](#crl-structure)
+ [Zugriffsrichtlinien für CRLs in Amazon S3](#s3-policies)
+ [Aktivieren Sie S3 Block Public Access (BPA) mit CloudFront](#s3-bpa)
+ [Ermitteln des CRL Distribution Point (CDP) -URI](#crl-url)
+ [](#crl-ipv6)
## CRL-Typen
+ **Vollständig** — Die Standardeinstellung. AWS Private CA verwaltet eine einzige, unpartitionierte CRL-Datei für alle nicht abgelaufenen Zertifikate, die von einer Zertifizierungsstelle ausgestellt wurden und gesperrt wurden. [Jedes ausgestellte Zertifikat ist AWS Private CA über seine CDP-Erweiterung (CRL Distribution Point) an eine bestimmte CRL gebunden, wie in RFC 5280 definiert.](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.9) Sie können bis zu 1 Million private Zertifikate für jede Zertifizierungsstelle haben, wenn die vollständige CRL aktiviert ist. Weitere Informationen finden Sie in den [AWS Private CA Kontingenten](https://docs.aws.amazon.com/general/latest/gr/pca.html#limits_pca).
+ **Partitioniert** — Im Vergleich zu vollständig CRLs, partitioniert erhöht CRLs sich die Anzahl der Zertifikate, die Ihre private Zertifizierungsstelle ausstellen kann, erheblich und erspart Ihnen das häufige Wechseln Ihrer Zertifikate. CAs
**Wichtig**
Wenn Sie partitioniert verwenden CRLs, müssen Sie überprüfen, ob die der CRL zugeordnete IDP-URI (Issuing Distribution Point) mit der CDP-URI des Zertifikats übereinstimmt, um sicherzustellen, dass die richtige CRL abgerufen wurde. AWS Private CA markiert die IDP-Erweiterung als kritisch. Ihr Client muss sie verarbeiten können.
## CRL-Struktur
Jede CRL ist eine DER-codierte Datei. Verwenden Sie einen Befehl, der dem folgenden ähnelt, um die Datei herunterzuladen und mit [OpenSSL](https://www.openssl.org/) anzuzeigen:
```
openssl crl -inform DER -in path-to-crl-file -text -noout
```
CRLs haben das folgende Format:
```
Certificate Revocation List (CRL):
Version 2 (0x1)
Signature Algorithm: sha256WithRSAEncryption
Issuer: /C=US/ST=WA/L=Seattle/O=Example Company CA/OU=Corporate/CN=www.example.com
Last Update: Feb 26 19:28:25 2018 GMT
Next Update: Feb 26 20:28:25 2019 GMT
CRL extensions:
X509v3 Authority Key Identifier:
keyid:AA:6E:C1:8A:EC:2F:8F:21:BC:BE:80:3D:C5:65:93:79:99:E7:71:65
X509v3 CRL Number:
1519676905984
Revoked Certificates:
Serial Number: E8CBD2BEDB122329F97706BCFEC990F8
Revocation Date: Feb 26 20:00:36 2018 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Key Compromise
Serial Number: F7D7A3FD88B82C6776483467BBF0B38C
Revocation Date: Jan 30 21:21:31 2018 GMT
CRL entry extensions:
X509v3 CRL Reason Code:
Key Compromise
Signature Algorithm: sha256WithRSAEncryption
82:9a:40:76:86:a5:f5:4e:1e:43:e2:ea:83:ac:89:07:49:bf:
c2:fd:45:7d:15:d0:76:fe:64:ce:7b:3d:bb:4c:a0:6c:4b:4f:
9e:1d:27:f8:69:5e:d1:93:5b:95:da:78:50:6d:a8:59:bb:6f:
49:9b:04:fa:38:f2:fc:4c:0d:97:ac:02:51:26:7d:3e:fe:a6:
c6:83:34:b4:84:0b:5d:b1:c4:25:2f:66:0a:2e:30:f6:52:88:
e8:d2:05:78:84:09:01:e8:9d:c2:9e:b5:83:bd:8a:3a:e4:94:
62:ed:92:e0:be:ea:d2:59:5b:c7:c3:61:35:dc:a9:98:9d:80:
1c:2a:f7:23:9b:fe:ad:6f:16:7e:22:09:9a:79:8f:44:69:89:
2a:78:ae:92:a4:32:46:8d:76:ee:68:25:63:5c:bd:41:a5:5a:
57:18:d7:71:35:85:5c:cd:20:28:c6:d5:59:88:47:c9:36:44:
53:55:28:4d:6b:f8:6a:00:eb:b4:62:de:15:56:c8:9c:45:d7:
83:83:07:21:84:b4:eb:0b:23:f2:61:dd:95:03:02:df:0d:0f:
97:32:e0:9d:38:de:7c:15:e4:36:66:7a:18:da:ce:a3:34:94:
58:a6:5d:5c:04:90:35:f1:8b:55:a9:3c:dd:72:a2:d7:5f:73:
5a:2c:88:85
```
**Anmerkung**
Die CRL wird erst in Amazon S3 hinterlegt, nachdem ein Zertifikat ausgestellt wurde, das darauf verweist. Davor war nur eine `acm-pca-permission-test-key` Datei im Amazon S3 S3-Bucket sichtbar.
## Zugriffsrichtlinien für CRLs in Amazon S3
Wenn Sie eine CRL erstellen möchten, müssen Sie einen Amazon S3 S3-Bucket vorbereiten, in dem sie gespeichert werden kann. AWS Private CA hinterlegt die CRL automatisch in dem von Ihnen Amazon S3 S3-Bucket und aktualisiert sie regelmäßig. Weitere Informationen finden Sie unter [Bucket erstellen](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket.html).
Ihr S3-Bucket muss durch eine beigefügte IAM-Berechtigungsrichtlinie gesichert sein. Autorisierte Benutzer und Dienstprinzipale benötigen die `Put` Erlaubnis, Objekte im Bucket platzieren AWS Private CA zu dürfen, und die `Get` Erlaubnis, sie abzurufen.
**Anmerkung**
Die Konfiguration der IAM-Richtlinie hängt von den AWS-Regionen beteiligten Personen ab. Regionen lassen sich in zwei Kategorien einteilen:
**Standardmäßig aktivierte Regionen — Regionen**, die standardmäßig für alle *aktiviert* sind. AWS-Konten
**Standardmäßig deaktivierte Regionen — Regionen, die standardmäßig *deaktiviert* sind, aber vom Kunden manuell** aktiviert werden können.
[Weitere Informationen und eine Liste der standardmäßig deaktivierten Regionen finden Sie unter Verwalten. AWS-Regionen](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html) Eine Erläuterung von Service Principals im Kontext von IAM finden Sie unter [AWS Service](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html#principal-services-in-opt-in-regions) Principals in Opt-in-Regionen.
Bei der Konfiguration CRLs als Methode zum Widerruf von Zertifikaten AWS Private CA wird eine CRL erstellt und in einem S3-Bucket veröffentlicht. Für den S3-Bucket ist eine IAM-Richtlinie erforderlich, die es dem AWS Private CA Dienstprinzipal ermöglicht, in den Bucket zu schreiben. Der Name des Service Principal variiert je nach den verwendeten Regionen, und es werden nicht alle Möglichkeiten unterstützt.
****
| PCA | S3 | Dienstauftraggeber |
| --- | --- | --- |
| Beide in derselben Region | `acm-pca.amazonaws.com` |
| Aktiviert | Enabled | `acm-pca.amazonaws.com` |
| Disabled | Aktiviert | `acm-pca.Region.amazonaws.com` |
| Enabled | Disabled | Nicht unterstützt |
Die Standardrichtlinie gilt `SourceArn` nicht für die CA. Wir empfehlen Ihnen, eine weniger freizügige Richtlinie wie die folgende anzuwenden, die den Zugriff sowohl auf ein bestimmtes AWS Konto als auch auf eine bestimmte private Zertifizierungsstelle beschränkt. Alternativ können Sie den Bedingungsschlüssel [aws: SourceOrg ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourceorgid) verwenden, um den Zugriff auf eine bestimmte Organisation in einzuschränken. AWS Organizations Weitere Informationen zu Bucket-Richtlinien finden Sie unter [Bucket-Richtlinien für Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-policies.html).
Wenn Sie sich dafür entscheiden, die Standardrichtlinie zuzulassen, können Sie sie später jederzeit [ändern](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html).
## Aktivieren Sie S3 Block Public Access (BPA) mit CloudFront
Neue Amazon S3 S3-Buckets werden standardmäßig mit aktivierter Funktion Block Public Access (BPA) konfiguriert. BPA gehört zu den [bewährten Sicherheitsmethoden](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html) von Amazon S3 und ist eine Reihe von Zugriffskontrollen, mit denen Kunden den Zugriff auf Objekte in ihren S3-Buckets und auf die Buckets insgesamt optimieren können. Wenn BPA aktiv und korrekt konfiguriert ist, haben nur autorisierte und authentifizierte AWS Benutzer Zugriff auf einen Bucket und seinen Inhalt.
AWS empfiehlt die Verwendung von BPA für alle S3-Buckets, um zu verhindern, dass vertrauliche Informationen potenziellen Gegnern zugänglich gemacht werden. Zusätzliche Planung ist jedoch erforderlich, wenn Ihre PKI-Clients Daten CRLs über das öffentliche Internet abrufen (d. h., wenn Sie nicht bei einem Konto angemeldet sind). AWS In diesem Abschnitt wird beschrieben, wie Sie eine private PKI-Lösung mithilfe von Amazon CloudFront, einem Content Delivery Network (CDN), für die Bereitstellung konfigurieren, CRLs ohne dass ein authentifizierter Client-Zugriff auf einen S3-Bucket erforderlich ist.
**Anmerkung**
Bei der Nutzung CloudFront fallen zusätzliche Kosten für Ihr Konto an. AWS Weitere Informationen finden Sie unter [ CloudFront Amazon-Preise](https://aws.amazon.com/cloudfront/pricing/).
Wenn Sie Ihre CRL in einem S3-Bucket mit aktiviertem BPA speichern und diese nicht verwenden, müssen Sie eine weitere CDN-Lösung entwickeln CloudFront, um sicherzustellen, dass Ihr PKI-Client Zugriff auf Ihre CRL hat.
### Für BPA einrichten CloudFront
Erstellen Sie eine CloudFront Distribution, die Zugriff auf Ihren privaten S3-Bucket hat und nicht authentifizierte CRLs Clients bedienen kann.
**Um eine CloudFront Distribution für die CRL zu konfigurieren**
1. Erstellen Sie eine neue CloudFront Distribution, indem Sie das Verfahren unter [Creating a Distribution](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-creating-console.html) im *Amazon CloudFront Developer Guide* verwenden.
Wenden Sie beim Abschluss des Verfahrens die folgenden Einstellungen an:
+ Wählen Sie **unter Origin Domain Name** Ihren S3-Bucket aus.
+ Wählen Sie **Ja für „****Bucket-Zugriff einschränken**“.
+ Wähle „**Neue Identität erstellen**“ für **Origin Access Identity** aus.
+ Wähle **Ja, Bucket-Richtlinie aktualisieren** unter **Leseberechtigungen für Bucket gewähren** aus.
**Anmerkung**
In diesem Verfahren wird Ihre Bucket-Richtlinie so CloudFront geändert, dass sie auf Bucket-Objekte zugreifen kann. Erwägen Sie, diese Richtlinie so zu [bearbeiten](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html), dass nur auf Objekte im `crl` Ordner zugegriffen werden kann.
1. Suchen Sie nach der Initialisierung der Distribution ihren Domänennamen in der CloudFront Konsole und speichern Sie ihn für den nächsten Vorgang.
**Anmerkung**
Wenn Ihr S3-Bucket in einer anderen Region als us-east-1 neu erstellt wurde, erhalten Sie möglicherweise einen temporären HTTP 307-Umleitungsfehler, wenn Sie über auf Ihre veröffentlichte Anwendung zugreifen. CloudFront Es kann mehrere Stunden dauern, bis die Adresse des Buckets weitergegeben wird.
### Richten Sie Ihre CA für BPA ein
Fügen Sie bei der Konfiguration Ihrer neuen CA den Alias zu Ihrer CloudFront Distribution hinzu.
**Um Ihre CA mit einem CNAME zu konfigurieren für CloudFront**
+ Erstellen Sie Ihre CA mit[Erstellen Sie eine private CA in AWS Private CA](create-CA.md).
Wenn Sie das Verfahren ausführen, `revoke_config.txt` sollte die Sperrdatei die folgenden Zeilen enthalten, um ein nichtöffentliches CRL-Objekt anzugeben und eine URL zum Verteilungsendpunkt in bereitzustellen: CloudFront
```
"S3ObjectAcl":"BUCKET_OWNER_FULL_CONTROL",
"CustomCname":"abcdef012345.cloudfront.net"
```
Wenn Sie anschließend Zertifikate mit dieser Zertifizierungsstelle ausstellen, enthalten sie einen Block wie den folgenden:
```
X509v3 CRL Distribution Points:
Full Name:
URI:http://abcdef012345.cloudfront.net/crl/01234567-89ab-cdef-0123-456789abcdef.crl
```
**Anmerkung**
Wenn Sie über ältere Zertifikate verfügen, die von dieser Zertifizierungsstelle ausgestellt wurden, können diese nicht auf die CRL zugreifen.
## Ermitteln des CRL Distribution Point (CDP) -URI
Wenn Sie den CRL Distribution Point (CDP) -URI in Ihrem Workflow verwenden müssen, können Sie entweder ein Zertifikat ausstellen, indem Sie den CRL-URI auf diesem Zertifikat verwenden oder die folgende Methode verwenden. Dies funktioniert nur, wenn der Vorgang abgeschlossen ist. CRLs An Partitionen wird CRLs eine zufällige GUID angehängt.
Wenn Sie den S3-Bucket als CRL Distribution Point (CDP) für Ihre CA verwenden, kann der CDP-URI eines der folgenden Formate haben.
+ `http://amzn-s3-demo-bucket.s3.region-code.amazonaws.com/crl/CA-ID.crl`
+ `http://s3.region-code.amazonaws.com/amzn-s3-demo-bucket/crl/CA-ID.crl`
Wenn Sie Ihre CA mit einem benutzerdefinierten CNAME konfiguriert haben, enthält der CDP-URI den CNAME, zum Beispiel `http://alternative.example.com/crl/CA-ID.crl`
##
AWS Private CA Schreibt CDP-Erweiterungen standardmäßig mit regionalen Endpunkten, die nur verfügbar sind. IPv4 `amazonaws.com` Um CRLs over zu verwenden IPv6, führen Sie einen der folgenden Schritte aus, sodass dieser Punkt auf CDPs die URLs Dual-Stack-Endpunkte [von S3](https://docs.aws.amazon.com/AmazonS3/latest/API/dual-stack-endpoints.html) geschrieben wird:
+ Legen Sie Ihren [benutzerdefinierten CRL-Namen](create-CA.md#PcaCreateRevocation) auf die S3-Dualstack-Endpunktdomäne fest. Beispiel: `bucketname.s3.dualstack.region-code.amazonaws.com`
+ Richten Sie Ihren eigenen CNAME-DNS-Eintrag ein, der auf den entsprechenden S3-Dualstack-Endpunkt verweist, und verwenden Sie ihn dann als Ihren benutzerdefinierten CRL-Namen
# Passen Sie die OCSP-URL an für AWS Private CA
**Anmerkung**
Dieses Thema richtet sich an Kunden, die die öffentliche URL des OCSP-Responder-Endpunkts (Online Certificate Status Protocol) für Branding- oder andere Zwecke anpassen möchten. [Wenn Sie die Standardkonfiguration von AWS Private CA verwaltetem OCSP verwenden möchten, können Sie dieses Thema überspringen und den Konfigurationsanweisungen unter Sperre konfigurieren folgen.](create-CA.md#PcaCreateRevocation)
Wenn Sie OCSP für aktivieren, enthält jedes Zertifikat AWS Private CA, das Sie ausstellen, standardmäßig die URL für den AWS OCSP-Responder. Auf diese Weise können Clients, die eine kryptografisch sichere Verbindung anfordern, OCSP-Validierungsanfragen direkt an diese senden. AWS In einigen Fällen kann es jedoch vorzuziehen sein, in Ihren Zertifikaten eine andere URL anzugeben, während Sie letztendlich OCSP-Abfragen an senden. AWS
**Anmerkung**
Informationen zur Verwendung einer Zertifikatssperrliste (CRL) als Alternative oder Ergänzung zu OCSP finden [Sie unter Sperrung konfigurieren](create-CA.md#PcaCreateRevocation) und [Planung einer Zertifikatssperrliste (](crl-planning.md)CRL).
Bei der Konfiguration einer benutzerdefinierten URL für OCSP sind drei Elemente erforderlich.
+ **CA-Konfiguration** — Geben Sie in der `RevocationConfiguration` für Ihre CA eine benutzerdefinierte OCSP-URL an, wie unter beschrieben[Beispiel 2: Erstellen Sie eine CA mit aktiviertem OCSP und einem benutzerdefinierten CNAME](create-CA.md#example_2). [Erstellen Sie eine private CA in AWS Private CA](create-CA.md)
+ **DNS** — Fügen Sie Ihrer Domain-Konfiguration einen CNAME-Eintrag hinzu, um die in den Zertifikaten angezeigte URL einer Proxyserver-URL zuzuordnen. Weitere Informationen finden Sie unter [Beispiel 2: Erstellen Sie eine CA mit aktiviertem OCSP und einem benutzerdefinierten CNAME](create-CA.md#example_2) in [Erstellen Sie eine private CA in AWS Private CA](create-CA.md).
+ **Proxyserver weiterleiten** — Richten Sie einen Proxyserver ein, der den empfangenen OCSP-Verkehr transparent an den OCSP-Responder AWS weiterleiten kann.
Das folgende Diagramm zeigt, wie diese Elemente zusammenarbeiten.
![\[Benutzerdefinierte OCSP-Topologie\]](http://docs.aws.amazon.com/de_de/privateca/latest/userguide/images/ocsp.png)
Wie im Diagramm dargestellt, umfasst der benutzerdefinierte OCSP-Validierungsprozess die folgenden Schritte:
1. Der Client fragt DNS für die Zieldomäne ab.
1. Der Client empfängt die Ziel-IP.
1. Der Client öffnet eine TCP-Verbindung mit dem Ziel.
1. Der Client erhält das Ziel-TLS-Zertifikat.
1. Der Client fragt DNS für die im Zertifikat aufgeführte OCSP-Domäne ab.
1. Der Client erhält eine Proxy-IP.
1. Der Client sendet eine OCSP-Anfrage an den Proxy.
1. Der Proxy leitet die Anfrage an den OCSP-Responder weiter.
1. Der Responder gibt den Zertifikatsstatus an den Proxy zurück.
1. Der Proxy leitet den Zertifikatsstatus an den Client weiter.
1. Wenn das Zertifikat gültig ist, beginnt der Client mit dem TLS-Handshake.
**Tipp**
Dieses Beispiel kann mit [Amazon CloudFront und Amazon](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/) [Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/) implementiert werden, nachdem Sie eine CA wie oben beschrieben konfiguriert haben.
Erstellen Sie in CloudFront eine Distribution und konfigurieren Sie sie wie folgt:
Erstellen Sie einen alternativen Namen, der Ihrem benutzerdefinierten CNAME entspricht.
Binden Sie Ihr Zertifikat daran.
`ocsp.acm-pca..amazonaws.com`Als Ursprung festlegen.
Verwenden Sie den Dualstack-Endpunkt, um IPv6 Verbindungen zu verwenden `acm-pca-ocsp..api.aws`
Wenden Sie die Richtlinie an`Managed-CachingDisabled`.
Stellen Sie die **Viewer-Protokollrichtlinie** auf **HTTP und HTTPS** ein.
Stellen Sie die **zulässigen HTTP-Methoden** auf **GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE** ein.
Erstellen Sie in Route 53 einen DNS-Eintrag, der Ihren benutzerdefinierten CNAME der URL der CloudFront Distribution zuordnet.
## Verwenden Sie OCSP über IPv6
Die AWS Private CA Standard-OCSP-Responder-URL ist -only. IPv4 Um OCSP over zu verwenden IPv6, konfigurieren Sie eine benutzerdefinierte OCSP-URL für Ihre CA. Die URL kann entweder sein:
+ Der FQDN des Dual-Stack-PCA-OCSP-Responders, der das folgende Format hat `acm-pca-ocsp.region-name.api.aws`
+ Ein CNAME-Eintrag, den Sie so konfiguriert haben, dass er auf den Dual-Stack-OCSP-Responder verweist, wie oben beschrieben.
# AWS Private CA Verstehen Sie die CA-Modi
AWS Private CA unterstützt die Erstellung einer Zertifizierungsstelle (CA) in einem von zwei Modi. Die Modi „Allzweck-Zertifikat“ und „Kurzlebiges Zertifikat“ wirken sich auf die zulässige Gültigkeitsdauer der von der Zertifizierungsstelle ausgestellten Zertifikate aus.
**Anmerkung**
AWS Private CA führt keine Gültigkeitsprüfungen für Root-CA-Zertifikate durch.
## Universell einsetzbar (Standard)
In diesem Modus kann die CA Zertifikate mit beliebiger Gültigkeitsdauer ausstellen. Die meisten Anwendungen verwenden Zertifikate dieses Typs. In der Regel spezifiziert die CA auch einen Sperrmechanismus.
## Kurzlebiges Zertifikat
In diesem Modus wird eine Zertifizierungsstelle definiert, die ausschließlich Zertifikate mit einer maximalen Gültigkeitsdauer von sieben Tagen ausstellt. Diese kurzlebigen Zertifikate laufen so schnell ab, dass sie ohne einen Sperrmechanismus bereitgestellt werden können. Für einige Anwendungen ist es sinnvoller, häufig kurzlebige Zertifikate bereitzustellen, als den Netzwerk- und Verarbeitungsaufwand durch den Widerruf auf sich zu nehmen.
Kurzlebige Zertifikate müssen die letzte Zertifizierungsstelle in der Zertifikatshierarchie sein. Es entsteht ein erheblicher Mehraufwand, da die private CA alle sieben Tage erneuert werden muss.
CAs Der kurzlebige Zertifikatsmodus kostet weniger als der allgemeine CAs Zertifikatsmodus. Weitere Informationen finden Sie unter [AWS Private Certificate Authority – Preise](https://aws.amazon.com/private-ca/pricing/).
Um eine Zertifizierungsstelle zu erstellen, die kurzlebige Zertifikate ausstellt, setzen Sie den `UsageMode` Parameter mithilfe der Prozedur zum [Erstellen einer Zertifizierungsstelle](create-CA.md) auf kurzlebiges Zertifikat.
**Anmerkung**
AWS Certificate Manager kann keine Zertifikate ausstellen, die von einer privaten Zertifizierungsstelle im kurzlebigen Modus signiert wurden.
Die Verwendung von kurzlebigen Zertifikaten wird von den folgenden AWS Diensten unterstützt:
+ [Amazon AppStream](https://docs.aws.amazon.com/appstream/latest/developerguide/)
+ [Amazon WorkSpaces](https://docs.aws.amazon.com/workspaces/latest/adminguide/)
# Planen Sie für Resilienz in AWS Private CA
Die AWS globale Infrastruktur basiert auf AWS Regionen und Availability Zones. AWS Regionen bieten mehrere physisch getrennte und isolierte Availability Zones, die über Netzwerke mit niedriger Latenz, hohem Durchsatz und hoher Redundanz miteinander verbunden sind. Mithilfe von Availability Zones können Sie Anwendungen und Datenbanken erstellen und ausführen, die automatisch Failover zwischen Zonen ausführen, ohne dass es zu Unterbrechungen kommt. Availability Zones sind besser verfügbar, fehlertoleranter und skalierbarer als herkömmliche Infrastrukturen mit einem oder mehreren Rechenzentren.
Weitere Informationen zu AWS Regionen und Availability Zones finden Sie unter [AWS Globale](https://aws.amazon.com/about-aws/global-infrastructure/) Infrastruktur.
## Redundanz und Disaster Recovery
Berücksichtigen Sie Redundanz und DR bei der Planung Ihrer CA-Hierarchie. AWS Private CA ist in mehreren [Regionen](https://docs.aws.amazon.com/general/latest/gr/pca.html) verfügbar, sodass Sie Redundanzen CAs in mehreren Regionen einrichten können. Für den AWS Private CA Service gilt ein [Service Level Agreement](https://aws.amazon.com/certificate-manager/private-certificate-authority/sla/) (SLA) mit einer Verfügbarkeit von 99,9%. Es gibt mindestens zwei Ansätze, die Sie für Redundanz und Notfallwiederherstellung in Betracht ziehen können. Sie können Redundanz an der Stamm-CA oder an der höchsten untergeordneten CA konfigurieren. Jeder Ansatz hat Vor- und Nachteile.
1. Aus Redundanz- und Notfallwiederherstellungsgründen können Sie zwei Roots CAs in zwei verschiedenen AWS Regionen einrichten. Bei dieser Konfiguration arbeitet jede Stammzertifizierungsstelle unabhängig in einer AWS Region, sodass Sie im Falle eines Notfalls in einer Region geschützt sind. Das Erstellen redundanter Root-Zertifikate erhöht CAs jedoch die betriebliche Komplexität: Sie müssen beide Root-CA-Zertifikate an die Vertrauensspeicher der Browser und Betriebssysteme in Ihrer Umgebung verteilen.
1. Sie können auch redundante untergeordnete Zertifikate CAs einrichten, die in jeder Ihrer AWS Regionen bereitgestellt werden, und diese an dieselbe eindeutige Stammzertifizierungsstelle in einer einzigen AWS Region anhängen. Der Vorteil dieses Ansatzes besteht darin, dass Sie nur ein einzelnes Stamm-CA-Zertifikat an die Vertrauensspeicher in Ihrer Umgebung verteilen müssen. Die Einschränkung besteht darin, dass Sie für den Fall einer Katastrophe, die sich auf die AWS Region auswirkt, in der sich Ihre Stammzertifizierungsstelle befindet, nicht über eine redundante Stammzertifizierungsstelle verfügen.