

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.

# Zertifikatbasierte Authentifizierung
<a name="certificate-based-authentication"></a>

Sie können die zertifikatsbasierte Authentifizierung mit WorkSpaces Anwendungsflotten verwenden, die mit Microsoft Active Directory verknüpft sind. Dadurch wird die Benutzeraufforderung zur Eingabe des Active-Directory-Domainkennworts entfernt, wenn sich ein Benutzer anmeldet. Durch die Verwendung der zertifikatsbasierten Authentifizierung mit Ihrer Active Directory-Domain können Sie Folgendes erreichen:
+ Sie können den SAML-2.0-Identitätsanbieter zur Authentifizierung der Benutzer und Bereitstellung der SAML-Zusicherungen für die Benutzer in Active Directory verwenden.
+ Ermöglichen Sie eine Single-Sign-On-Anmeldung mit weniger Benutzeraufforderungen.
+ Aktivieren Sie passwortlose Authentifizierungsabläufe mit Ihrem SAML-2.0-Identitätsanbieter.

Die zertifikatsbasierte Authentifizierung verwendet Ressourcen der AWS privaten Zertifizierungsstelle (AWS Private CA) in Ihrem. AWS-Konto Mit AWS Private CA können Sie private Zertifizierungsstellenhierarchien (CA) erstellen, einschließlich Stamm- und untergeordneter Zertifizierungsstellen. CAs Sie können auch Ihre eigene CA-Hierarchie erstellen und damit Zertifikate zur Authentifizierung interner Benutzer ausstellen. Weitere Informationen finden Sie unter [Was ist](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html). AWS Private CA

Wenn Sie AWS Private CA für die zertifikatsbasierte Authentifizierung verwenden, fordert WorkSpaces Applications bei der Sitzungsreservierung für jede WorkSpaces Applications-Flotteninstanz automatisch Zertifikate für Ihre Benutzer an. Die Benutzer werden mit einer virtuellen Smartcard, die mit den Zertifikaten bereitgestellt wird, bei Active Directory authentifiziert.

Die zertifikatsbasierte Authentifizierung (CBA) wird für in eine Domäne eingebundene WorkSpaces Anwendungsflotten (sowohl Flotten mit einer Sitzung als auch mit mehreren Sitzungen) unterstützt, auf denen Windows-Instances ausgeführt werden. Um CBA auf Flotten mit mehreren Sitzungen zu aktivieren, müssen Sie ein Anwendungs-Image verwenden, das einen WorkSpaces Anwendungsagenten verwendet, der am oder nach dem 02.07.2025 veröffentlicht wurde. WorkSpaces Oder Ihr Image muss Image-Updates für verwaltete WorkSpaces Anwendungen verwenden, die am oder nach dem 02.11.2025 veröffentlicht wurden. 

**Topics**
+ [Voraussetzungen](certificate-based-authentication-prereq.md)
+ [Aktivieren der zertifikatsbasierten Authentifizierung](certificate-based-authentication-enable.md)
+ [Verwalten der zertifikatsbasierten Authentifizierung](certificate-based-authentication-manage.md)
+ [Aktivieren Sie kontoübergreifendes PCA Sharing](pca-sharing.md)

# Voraussetzungen
<a name="certificate-based-authentication-prereq"></a>

Führen Sie die folgenden Schritte aus, bevor Sie die zertifikatbasierte Authentifizierung aktivieren.

1. Richten Sie eine mit einer Domain verbundene Flotte ein und konfigurieren Sie SAML 2.0. Stellen Sie sicher, dass Sie das Format `username@domain.com` `userPrincipalName` für das SAML\$1Subject `NameID` verwenden. Weitere Informationen finden Sie unter [Schritt 5: Erstellen von Zusicherungen für die SAML-Authentifizierungsantwort](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions).
**Anmerkung**  
Aktivieren Sie die **Smartcard-Anmeldung für Active Directory** nicht in Ihrem Stack, wenn Sie die zertifikatbasierte Authentifizierung verwenden möchten. Weitere Informationen finden Sie unter [Smartcards](feature-support-USB-devices-qualified.md#feature-support-USB-devices-qualified-smart-cards). 

1. Verwenden Sie WorkSpaces Applications Agent Version 10-13-2022 oder höher mit Ihrem Image. Weitere Informationen finden Sie unter [Behalten Sie Ihr WorkSpaces Amazon-Anwendungsimage Up-to-Date](keep-image-updated.md).

1. Konfigurieren Sie das `ObjectSid` Attribut in Ihrer SAML-Zusicherung. Sie können dieses Attribut verwenden, um eine starke Zuordnung mit dem Active-Directory-Benutzer durchzuführen. Die zertifikatsbasierte Authentifizierung schlägt fehl, wenn das Attribut `ObjectSid` nicht mit der Active-Directory-Sicherheitskennung (SID) für den im SAML\$1Subject `NameID` angegebenen Benutzenden übereinstimmt. Weitere Informationen finden Sie unter [Schritt 5: Erstellen von Zusicherungen für die SAML-Authentifizierungsantwort](external-identity-providers-setting-up-saml.md#external-identity-providers-create-assertions). Das `ObjectSid` ist für die zertifikatsbasierte Authentifizierung nach dem 10. September 2025 verpflichtend. Weitere Informationen finden Sie unter [KB5014754: Änderungen der zertifikatsbasierten Authentifizierung auf Windows-Domänencontrollern](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16).

1. Fügen Sie die Berechtigung `sts:TagSession` zur Vertrauensrichtlinie für IAM-Rollen hinzu, die Sie mit Ihrer SAML-2.0-Konfiguration verwenden. Weitere Informationen finden Sie unter [Übergeben von Sitzungs-Tags in AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html.html). Diese Berechtigung ist erforderlich, um die zertifikatsbasierte Authentifizierung zu verwenden. Weitere Informationen finden Sie unter [Schritt 2: Erstellen einer IAM-Rolle für den SAML-2.0-Verbund](external-identity-providers-setting-up-saml.md#external-identity-providers-grantperms).

1. Erstellen Sie eine private Zertifizierungsstelle (CA) mithilfe von AWS Private CA, falls Sie noch keine mit Ihrem Active Directory konfiguriert haben. AWS Für die Verwendung der zertifikatsbasierten Authentifizierung ist eine private Zertifizierungsstelle erforderlich. Weitere Informationen finden Sie unter [Planen der Bereitstellung der AWS Private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaPlanning.html). Die folgenden Einstellungen für AWS private Zertifizierungsstellen sind für viele Anwendungsfälle der zertifikatsbasierten Authentifizierung üblich:
   + **Optionen für den CA-Typ**
     + **CA-Verwendungsmodus für kurzlebige Zertifikate** – empfohlen, wenn Sie die CA nur zur Ausstellung von Endbenutzerzertifikaten für die zertifikatsbasierte Authentifizierung verwenden.
     + **Einstufige Hierarchie mit einer Stammzertifizierungsstelle** –Wählen Sie eine untergeordnete Zertifizierungsstelle aus, wenn Sie eine Integration in eine bestehende Zertifizierungsstellenhierarchie vornehmen möchten.
   + **Optionen für den Schlüsselalgorithmus** – RSA 2048
   + **Optionen für den definierten Namen des Antragstellers** – Verwenden Sie eine möglichst geeignete Kombination von Optionen, um diese Zertifizierungsstelle in Ihrem Active-Directory-Speicher für vertrauenswürdige Stammzertifizierungsstellen zu identifizieren.
   + **Optionen zum Widerruf von Zertifikaten** – CRL-Verteilung
**Anmerkung**  
Für die zertifikatsbasierte Authentifizierung ist ein Online-CRL-Verteilungspunkt erforderlich, auf den sowohl von der WorkSpaces Applications Flotteninstanz als auch vom Domänencontroller aus zugegriffen werden kann. Dies erfordert einen nicht authentifizierten Zugriff auf den Amazon S3 S3-Bucket, der für AWS private CA-CRL-Einträge konfiguriert ist, oder eine CloudFront Distribution mit Zugriff auf den Amazon S3 S3-Bucket, falls dieser den öffentlichen Zugriff blockiert. Weitere Informationen finden Sie unter [Planen einer Zertifikatsperrliste (CRL)](https://docs.aws.amazon.com/privateca/latest/userguide/crl-planning.html).

1. Kennzeichnen Sie Ihre private CA mit einem Schlüssel, der dazu berechtigt ist, die CA für die Verwendung mit WorkSpaces der zertifikatsbasierten Authentifizierung von Applications `euc-private-ca` zu kennzeichnen. Dieser Schlüssel benötigt keinen Wert. Weitere Informationen finden Sie unter [Verwalten von Tags für Ihre private CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCaTagging.html). Weitere Informationen zu den AWS verwalteten Richtlinien, die mit WorkSpaces Anwendungen verwendet werden, um Berechtigungen für Ressourcen in Ihrem AWS-Konto zu gewähren, finden Sie unter. [AWS Für den Zugriff auf WorkSpaces Anwendungsressourcen sind verwaltete Richtlinien erforderlich](managed-policies-required-to-access-appstream-resources.md)

1. Bei der zertifikatsbasierten Authentifizierung werden virtuelle Smartcards für die Anmeldung verwendet. Weitere Informationen finden Sie unter [Richtlinien für die Aktivierung der Smartcard-Anmeldung bei Zertifizierungsstellen von Drittanbietern](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities). Dazu gehen Sie wie folgt vor:

   1. Konfigurieren Sie Domaincontroller mit einem Domaincontrollerzertifikat, um Smartcard-Benutzer zu authentifizieren. Wenn Sie in Ihrem Active Directory eine Unternehmenszertifizierungsstelle für Active-Directory-Zertifikatsdienste konfiguriert haben, werden Domaincontroller automatisch mit Zertifikaten registriert, um die Smartcard-Anmeldung zu ermöglichen. Wenn Sie nicht über Active Directory-Zertifikatsdienste verfügen, finden Sie weitere Informationen unter [Anforderungen für Domänencontrollerzertifikate von einer Drittanbieter-Zertifizierungsstelle](https://learn.microsoft.com/en-US/troubleshoot/windows-server/windows-security/requirements-domain-controller). AWS empfiehlt Active Directory-Zertifizierungsstellen für Unternehmen, die Registrierung von Domänencontrollerzertifikaten automatisch zu verwalten.
**Anmerkung**  
Wenn Sie AWS Managed Microsoft AD verwenden, können Sie Certificate Services auf einer Amazon EC2 EC2-Instance konfigurieren, die die Anforderungen für Domain-Controller-Zertifikate erfüllt. Weitere Informationen finden Sie unter [Bereitstellen von Active Directory in einer neuen Amazon Virtual Private Cloud](https://docs.aws.amazon.com/launchwizard/latest/userguide/launch-wizard-ad-deploying-new-vpc.html), z. B. Bereitstellungen von AWS Managed Microsoft AD, konfiguriert mit Active Directory-Zertifikatsdiensten.  
Bei AWS Managed Microsoft AD und Active Directory Certificate Services müssen Sie auch Regeln für ausgehenden Datenverkehr von der VPC-Sicherheitsgruppe des Controllers zur Amazon EC2 EC2-Instance erstellen, auf der Certificate Services ausgeführt wird. Sie müssen der Sicherheitsgruppe Zugriff auf den TCP-Port 135 und die Ports 49152 bis 65535 gewähren, um die automatische Zertifikatsregistrierung zu aktivieren. Darüber hinaus muss die Amazon-EC2-Instance eingehenden Zugriff auf dieselben Ports von Domain-Instances, einschließlich Domaincontrollern, zulassen. Weitere Informationen zum Auffinden der Sicherheitsgruppe für AWS Managed Microsoft AD finden [Sie unter Konfigurieren Ihrer VPC-Subnetze und Sicherheitsgruppen](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_tutorial_setup_trust_prepare_mad.html#tutorial_setup_trust_open_vpc).

   1. Exportieren Sie das AWS private CA-Zertifikat auf der Private CA-Konsole oder mit dem SDK oder der CLI. Weitere Informationen finden Sie unter [Exportieren eines privaten Zertifikats](https://docs.aws.amazon.com/acm/latest/userguide/export-private.html).

   1. Veröffentlichen Sie die private CA in Active Directory. Melden Sie sich an einem Domaincontroller oder einem Computer an, der Domainmitglied ist. Kopieren Sie das private CA-Zertifikat in einen beliebigen `<path>\<file>` und führen Sie die folgenden Befehle als Domainadministrator aus. Sie können auch Gruppenrichtlinien und das Microsoft PKI Health Tool (PKIView) verwenden, um die CA zu veröffentlichen. Weitere Informationen finden Sie in den [Konfigurationsanweisungen](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities#configuration-instructions).

      ```
      certutil -dspublish -f <path>\<file> RootCA
      ```

      ```
      certutil -dspublish -f <path>\<file> NTAuthCA
      ```

      Stellen Sie sicher, dass die Befehle erfolgreich ausgeführt wurden. Entfernen Sie dann die private Zertifikatsdatei. Abhängig von Ihren Active Directory-Replikationseinstellungen kann es mehrere Minuten dauern, bis die CA auf Ihren Domänencontrollern und WorkSpaces Anwendungsflotteninstanzen veröffentlicht wird.
**Anmerkung**  
Active Directory muss die CA automatisch an die vertrauenswürdigen Stammzertifizierungsstellen und Enterprise NTAuth Stores für WorkSpaces Applications-Flotteninstanzen verteilen, wenn diese der Domäne beitreten.

Bei Windows-Betriebssystemen erfolgt die Verteilung der CA (Certificate Authority) automatisch. Für Rocky Linux und Red Hat Enterprise Linux müssen Sie jedoch das/die Root-CA-Zertifikat (e) von der CA herunterladen, die von Ihrer WorkSpaces Applications Directory Config verwendet wird. Wenn Ihre KDC-Root-CA-Zertifikate unterschiedlich sind, müssen Sie diese ebenfalls herunterladen. Bevor Sie die zertifikatsbasierte Authentifizierung verwenden können, müssen Sie diese Zertifikate in ein Image oder einen Snapshot importieren.

Auf dem Bild sollte sich eine Datei mit dem Namen/befinden. `etc/sssd/pki/sssd_auth_ca_db.pem` Sie sollte wie folgt aussehen:

```
-----BEGIN CERTIFICATE-----
Base64-encoded certificate chain from ACM Private CA 
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded certificate body from ACM private CA
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded root CA KDC certificate chain
-----END CERTIFICATE-----
```

**Anmerkung**  
Wenn Sie ein Bild zwischen Regionen oder Konten kopieren oder ein Bild erneut einem neuen Active Directory zuordnen, muss diese Datei vor der Verwendung mit den entsprechenden Zertifikaten in einem Image Builder neu konfiguriert und erneut als Snapshot erstellt werden.

Im Folgenden finden Sie Anweisungen zum Herunterladen der Root-CA-Zertifikate:

1. Erstellen Sie im Image Builder eine Datei mit dem Namen`/etc/sssd/pki/sssd_auth_ca_db.pem`.

1. Öffnen Sie die [AWS Private CA-Konsole](https://console.aws.amazon.com/acm-pca/).

1. Wählen Sie das private Zertifikat aus, das mit Ihrer WorkSpaces Anwendungsverzeichniskonfiguration verwendet wird.

1. Wählen Sie die Registerkarte **CA-Zertifikat**.

1. Kopieren Sie die Zertifikatskette und den `/etc/sssd/pki/sssd_auth_ca_db.pem` Zertifikatshauptteil in den Image Builder.

Wenn sich die von der verwendeten Root-CA-Zertifikate von dem KDCs unterscheiden, das von Ihrer WorkSpaces Applications Directory Config verwendet wird, gehen Sie wie folgt vor, um sie herunterzuladen:

1. Stellen Sie eine Connect zu einer Windows-Instanz her, die derselben Domäne angehört wie Ihr Image Builder.

1. Öffnen Sie `certlm.msc`.

1. Wählen Sie im linken Bereich **Trusted Root Certificate Authorities** und dann **Certificates** aus.

1. Öffnen Sie für jedes Root-CA-Zertifikat das Kontextmenü (Rechtsklick).

1. Wählen Sie **Alle Aufgaben**, dann **Exportieren**, um den Zertifikatsexport-Assistenten zu öffnen, und klicken Sie dann auf **Weiter**.

1. **Wählen Sie **Base64-encoded X.509 (.CER)** und dann Weiter.**

1. **Wählen Sie „**Durchsuchen**“, geben Sie einen Dateinamen ein und klicken Sie auf „Weiter“.**

1. Wählen Sie **Finish** (Abschließen).

1. Öffnen Sie das exportierte Zertifikat in einem Texteditor.

1. Kopieren Sie den Inhalt der Datei in `/etc/sssd/pki/sssd_auth_ca_db.pem` den Image Builder.

# Aktivieren der zertifikatsbasierten Authentifizierung
<a name="certificate-based-authentication-enable"></a>

Führen Sie die folgenden Schritte aus, um die zertifikatsbasierte Authentifizierung zu aktivieren.

**So aktivieren Sie die zertifikatsbasierte Authentifizierung**

1. Öffnen Sie die WorkSpaces Anwendungskonsole unter [https://console.aws.amazon.com/appstream2.](https://console.aws.amazon.com/appstream2)

1. Wählen Sie im Navigationsbereich **Directory-Konfigurationen** aus. Wählen Sie die Directory-Konfiguration aus, die Sie konfigurieren möchten, und klicken Sie auf **Bearbeiten**.

1. Wählen Sie **Zertifikatsbasierte Authentifizierung aktivieren** aus.

1. Vergewissern Sie sich, dass Ihr privater CA-ARN in der Liste zugeordnet ist. Um in der Liste angezeigt zu werden, sollten Sie die private CA im selben Land speichern. AWS-Konto AWS-Region Sie müssen die private Zertifizierungsstelle außerdem mit einem Schlüssel namens `euc-private-ca` kennzeichnen.

1. Konfigurieren Sie das Fallback für die Directory-Anmeldung. Fallback ermöglicht es Benutzern, sich mit ihrem AD-Domain-Passwort anzumelden, falls die zertifikatbasierte Authentifizierung nicht erfolgreich ist. Dies wird nur in Fällen empfohlen, in denen Benutzer ihre Domainpasswörter kennen. Wenn Fallback deaktiviert ist, kann eine Sitzung die Verbindung zum Benutzer trennen, wenn ein Sperrbildschirm angezeigt wird oder der Benutzer sich von Windows abmeldet. Wenn Fallback aktiviert ist, fordert die Sitzung den Benutzer zur Eingabe seines AD-Domainpassworts auf.

1. Wählen Sie **Save Changes**.

1. Die zertifikatsbasierte Authentifizierung ist nun aktiviert. Wenn sich Benutzer über den WorkSpaces Applications Web Client oder den Client für Windows (Version 1.1.1099 und höher) mit SAML 2.0 bei einem WorkSpaces Anwendungsstapel authentifizieren, werden sie nicht mehr zur Eingabe des Domänenkennworts aufgefordert. Benutzern wird die Meldung „Verbindung mit zertifikatsbasierter Authentifizierung wird hergestellt…“ angezeigt, wenn sie eine Verbindung zu einer Sitzung herstellen, für die zertifikatsbasierte Authentifizierung aktiviert ist.

# Verwalten der zertifikatsbasierten Authentifizierung
<a name="certificate-based-authentication-manage"></a>

Nachdem Sie die zertifikatsbasierte Authentifizierung aktiviert haben, gehen Sie die folgenden Aufgaben durch.

**Topics**
+ [Zertifikat einer privaten CA](certificate-based-authentication-manage-CA.md)
+ [Endbenutzerzertifikate](certificate-based-authentication-manage-certs.md)
+ [Prüfberichte](certificate-based-authentication-manage-audit.md)
+ [Protokollieren und Überwachen](certificate-based-authentication-manage-logging.md)

# Zertifikat einer privaten CA
<a name="certificate-based-authentication-manage-CA"></a>

In einer typischen Konfiguration hat das Zertifikat einer privaten CA eine Gültigkeitsdauer von 10 Jahren. Weitere Informationen zum Ersetzen einer privaten Zertifizierungsstelle mit einem abgelaufenen Zertifikat oder zur Neuausstellung der privaten Zertifizierungsstelle mit einem neuen Gültigkeitszeitraum finden Sie unter [Verwalten des Lebenszyklus einer privaten Zertifizierungsstelle](https://docs.aws.amazon.com/privateca/latest/userguide/ca-lifecycle.html). 

# Endbenutzerzertifikate
<a name="certificate-based-authentication-manage-certs"></a>

Endbenutzerzertifikate, die von der zertifikatsbasierten Authentifizierung von AWS Private CA for WorkSpaces Applications ausgestellt wurden, müssen nicht erneuert oder widerrufen werden. Diese Zertifikate sind kurzlebig. WorkSpaces Applications stellt automatisch für jede neue Sitzung oder alle 24 Stunden für Sitzungen mit langer Dauer ein neues Zertifikat aus. Die WorkSpaces Anwendungssitzung regelt die Verwendung dieser Endbenutzerzertifikate. Wenn Sie eine Sitzung beenden, verwendet WorkSpaces Applications dieses Zertifikat nicht mehr. Diese Endbenutzerzertifikate haben eine kürzere Gültigkeitsdauer als eine typische AWS Private CA CRL-Distribution. Daher müssen Endbenutzerzertifikate nicht gesperrt werden und erscheinen auch nicht in einer CRL. 

# Prüfberichte
<a name="certificate-based-authentication-manage-audit"></a>

Sie können einen Auditbericht erstellen, der die Zertifikate auflistet, die ihre private CA ausgestellt oder widerrufen hat. Weitere Informationen finden Sie unter [Verwenden von Prüfberichten mit Ihrer privaten CA](https://docs.aws.amazon.com/privateca/latest/userguide/PcaAuditReport.html).

# Protokollieren und Überwachen
<a name="certificate-based-authentication-manage-logging"></a>

Sie können sie verwenden CloudTrail , um API-Aufrufe von WorkSpaces Applications an eine private Zertifizierungsstelle aufzuzeichnen. Weitere Informationen finden Sie unter [Was ist AWS CloudTrail?](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) und [Verwenden CloudTrail](https://docs.aws.amazon.com/privateca/latest/userguide/PcaCtIntro.html). Im CloudTrail Ereignisverlauf können Sie die Namen der Ereignisse aus der **IssueCertificate**Ereignisquelle **acm-pca.amazonaws.com** einsehen **GetCertificate**, die anhand des Benutzernamens der Anwendung erstellt wurden. WorkSpaces **EcmAssumeRoleSession** Diese Ereignisse werden für jede auf einem Zertifikat basierende Authentifizierungsanfrage von Anwendungen aufgezeichnet. WorkSpaces Weitere Informationen finden Sie unter [Ereignisse mit dem CloudTrail Ereignisverlauf anzeigen](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).

# Aktivieren Sie kontoübergreifendes PCA Sharing
<a name="pca-sharing"></a>

Die kontenübergreifende Nutzung von Private CA (PCA) bietet die Möglichkeit, anderen Konten Berechtigungen zur Nutzung einer zentralen CA zu erteilen. Die CA kann Zertifikate generieren und ausstellen, indem sie [AWS Resource Access Manager](https://aws.amazon.com/ram/) (RAM) zur Verwaltung der Berechtigungen verwendet. Dadurch entfällt die Notwendigkeit einer privaten CA für jedes Konto. Die kontoübergreifende gemeinsame Nutzung von privaten Zertifizierungsstellen kann zusammen mit der zertifikatsbasierten Authentifizierung (CBA) für WorkSpaces Anwendungen innerhalb desselben verwendet werden. AWS-Region

Gehen Sie wie folgt vor, um eine gemeinsam genutzte private CA-Ressource mit WorkSpaces Applications CBA zu verwenden:

1. Konfigurieren Sie die private Zertifizierungsstelle für CBA in einer zentralen Umgebung. AWS-Konto Weitere Informationen finden Sie unter [Zertifikatbasierte Authentifizierung](certificate-based-authentication.md).

1. Teilen Sie die private CA mit der Ressource, für AWS-Konten die WorkSpaces Anwendungsressourcen CBA nutzen. Folgen Sie dazu den Schritten unter [So verwenden Sie AWS-RAM, um Ihr ACM Private CA-Cross-Konto gemeinsam zu](https://aws.amazon.com/blogs/security/how-to-use-aws-ram-to-share-your-acm-private-ca-cross-account/) nutzen. Sie müssen Schritt 3 nicht abschließen, um ein Zertifikat zu erstellen. Sie können die private Zertifizierungsstelle entweder mit einer Einzelperson AWS-Konten teilen oder über diese teilen AWS Organizations. Wenn Sie Daten mit einzelnen Konten teilen, müssen Sie die gemeinsame private Zertifizierungsstelle in Ihrem Ressourcenkonto akzeptieren, indem Sie die AWS Resource Access Manager Konsole oder verwenden APIs. 

   Stellen Sie bei der Konfiguration der Freigabe sicher, dass die AWS Resource Access Manager Ressourcenfreigabe für die private Zertifizierungsstelle im Ressourcenkonto die Vorlage für `AWSRAMBlankEndEntityCertificateAPICSRPassthroughIssuanceCertificateAuthority` verwaltete Berechtigungen verwendet. Diese Vorlage entspricht der PCA-Vorlage, die von der Servicerolle WorkSpaces Applications bei der Ausstellung von CBA-Zertifikaten verwendet wird.

1. Nachdem die Freigabe erfolgreich war, können Sie die gemeinsam genutzte private Zertifizierungsstelle mithilfe der privaten CA-Konsole im Ressourcenkonto aufrufen.

1. Verwenden Sie die API oder CLI, um den Private CA ARN mit CBA in Ihrer WorkSpaces Anwendungsverzeichniskonfiguration zu verknüpfen. Derzeit unterstützt die WorkSpaces Anwendungskonsole die Auswahl einer gemeinsam genutzten privaten CA ARNs nicht. Im Folgenden finden Sie Beispiele für CLI-Befehle:

   `aws appstream update-directory-config --directory-name <value> --certificate-based-auth-properties Status=<value>,CertificateAuthorityArn=<value>` 