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.
# 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.