Zertifikatanforderungen für Azure Stack Hub-PKI (Public Key-Infrastruktur)

Azure Stack Hub verfügt über ein öffentliches Infrastrukturnetz mit extern zugänglichen öffentlichen IP-Adressen, die einer kleinen Gruppe von Azure Stack Hub-Diensten und möglicherweise Mandanten-VMs zugewiesen sind. PKI-Zertifikate (Public Key-Infrastruktur) mit den entsprechenden DNS-Namen für diese Endpunkte der öffentlichen Infrastruktur von Azure Stack Hub werden während der Bereitstellung von Azure Stack Hub benötigt. Dieser Artikel enthält Informationen zu Folgendem:

• Zertifikatanforderungen für Azure Stack Hub.
• Erforderliche Zertifikate für die Azure Stack Hub-Bereitstellung.
• Optionale Zertifikate, die beim Bereitstellen von Ressourcenanbietern (RPs) erforderlich sind, die Mehrwert schaffen.

Hinweis

Azure Stack Hub verwendet standardmäßig auch Zertifikate, die von einer internen, in Active Directory integrierten Zertifizierungsstelle (Certificate Authority, CA) für die Authentifizierung zwischen den Knoten ausgestellt werden. Um das Zertifikat zu überprüfen, vertrauen alle Azure Stack Hub-Infrastrukturcomputer dem Stammzertifikat der internen Zertifizierungsstelle, indem sie dieses Zertifikat dem lokalen Zertifikatspeicher hinzufügen. In Azure Stack Hub werden keine Zertifikate angeheftet oder gefiltert. Der SAN der einzelnen Serverzertifikate wird anhand des FQDN des Ziels überprüft. Außerdem werden die gesamte Vertrauenskette sowie das Ablaufdatum des Zertifikats (standardmäßige TLS-Server-Authentifizierung ohne Anheften von Zertifikaten) überprüft.

Zertifikatanforderungen

In der folgenden Liste werden die allgemeinen Anforderungen an Zertifikatausstellung, Sicherheit und Formatierung beschrieben:

• Zertifikate müssen von einer internen oder öffentlichen Zertifizierungsstelle ausgestellt werden. Wenn eine öffentliche Zertifizierungsstelle verwendet wird, muss diese im Rahmen des Microsoft Trusted Root Authority Program in das Basisbetriebssystem-Image aufgenommen werden. Eine vollständige Liste finden Sie unter Teilnehmerliste des Microsoft Trusted Root Program.
• Ihre Azure Stack Hub-Infrastruktur muss über Netzwerkzugriff auf den im Zertifikat veröffentlichten Speicherort der Zertifikatsperrliste (Certificate Revocation List, CRL) der Zertifizierungsstelle verfügen. Bei dieser CRL muss es sich um einen HTTP-Endpunkt handeln. Hinweis: Bei nicht verbundenen Bereitstellungen werden Zertifikate, die von einer öffentlichen Zertifizierungsstelle ausgestellt wurden, nicht unterstützt, wenn nicht auf den CRL-Endpunkt zugegriffen werden kann. Weitere Informationen finden Sie unter Funktionen, die in von Azure getrennten Bereitstellungen eingeschränkt oder nicht verfügbar sind.

• Bei rotierenden Zertifikaten ab Build 1903 können Zertifikate von einer beliebigen Unternehmens- oder öffentlichen Zertifizierungsstelle ausgestellt werden.

• Die Verwendung selbstsignierter Zertifikate wird nicht unterstützt.
• Sie können bei der Bereitstellung und Rotation ein einzelnes Zertifikat verwenden, das alle Namespaces im Antragstellernamen und alternativen Antragstellernamen (SAN) des Zertifikats abdeckt. Alternativ können Sie einzelne Zertifikate für alle der im Folgenden angegebenen Namespaces verwenden, die die Azure Stack Hub-Dienste benötigen, die Sie verwenden möchten. Beide Ansätze erfordern bei Bedarf die Verwendung von Platzhaltern für Endpunkte, z. B. KeyVault und KeyVaultInternal.
• Der Zertifikatsignaturalgorithmus sollte nicht SHA-1 sein.
• Das Zertifikatsformat muss PFX sein, da sowohl der öffentliche als auch der private Schlüssel für die Installation von Azure Stack Hub benötigt werden. Für den privaten Schlüssel muss das Schlüsselattribut des lokalen Computers festgelegt sein.
• Die PFX-Verschlüsselung muss 3DES sein. (Dies ist beim Exportieren von einem Windows 10-Client oder einem Windows Server 2016-Zertifikatspeicher Standard.)
• Die PFX-Zertifikatdateien müssen im Feld „Schlüsselverwendung“ einen Wert in „Digitale Signatur“ und „Schlüsselchiffrierung“ enthalten.
• Die PFX-Zertifikatdateien müssen die Werte „Serverauthentifizierung (1.3.6.1.5.5.7.3.1)“ und „Clientauthentifizierung (1.3.6.1.5.5.7.3.2)“ im Feld „Erweiterte Schlüsselverwendung“ aufweisen.
• Das Feld „Ausgestellt für:“ des Zertifikats darf nicht mit dem Feld „Ausgestellt von:“ identisch sein.
• Die Kennwörter aller PFX-Zertifikatdateien müssen zum Zeitpunkt der Bereitstellung identisch sein.
• Für die PFX-Zertifikatdatei muss ein komplexes Kennwort verwendet werden. Notieren Sie sich dieses Kennwort, da Sie es später als Bereitstellungsparameter benötigen. Das Kennwort muss die folgenden Komplexitätsanforderungen erfüllen.
  • Mindestlänge von 8 Zeichen.
  • Mindestens drei der folgenden Elemente: Großbuchstaben, Kleinbuchstaben, Zahlen von 0–9, Sonderzeichen, alphabetische Zeichen, die weder Groß- noch Kleinbuchstaben sind.
• Stellen Sie sicher, dass die Antragstellernamen und alternativen Antragstellernamen in der Erweiterung für alternative Antragstellernamen (x509v3_config) übereinstimmen. Im Feld für den alternativen Antragstellernamen können Sie zusätzliche Hostnamen (Websites, IP-Adressen, allgemeine Namen) angeben, die durch ein einzelnes SSL-Zertifikat geschützt werden sollen.

Hinweis

Selbstsignierte Zertifikate werden nicht unterstützt.
Bei der Bereitstellung von Azure Stack Hub im getrennten Modus wird die Verwendung von Zertifikaten empfohlen, die von einer Unternehmenszertifizierungsstelle ausgestellt wurden. Dies ist wichtig, da Clients, die auf Azure Stack Hub-Endpunkte zugreifen, in der Lage sein müssen, eine Verbindung mit der Zertifikatsperrliste (Certificate Revocation List, CRL) herzustellen.

Hinweis

Das Vorhandensein von Zwischenzertifizierungsstellen in der Vertrauenskette eines Zertifikats wird unterstützt.

Erforderliche Zertifikate

In der Tabelle in diesem Abschnitt werden die PKI-Zertifikate des öffentlichen Azure Stack Hub-Endpunkts beschrieben, die sowohl für Microsoft Entra-ID- als auch für AD FS-Azure Stack Hub-Bereitstellungen erforderlich sind. Zertifikatsanforderungen werden nach Bereichen gruppiert, ebenso wie die verwendeten Namespaces und die Zertifikate, die für jeden Namespace benötigt werden. Die Tabelle beschreibt auch den Ordner, in den Ihr Lösungsanbieter die verschiedenen Zertifikate für jeden öffentlichen Endpunkt kopiert.

Zertifikate mit den entsprechenden DNS-Namen für diese Endpunkte der öffentlichen Infrastruktur von Azure Stack Hub sind erforderlich. Der DNS-Name von Endpunkten wird im folgenden Format angegeben: prefix>.<region>.<fqdn>.

Für Ihre Bereitstellung müssen die Werte region> und > mit der Region und den externen Domänennamen übereinstimmen, die Sie für Ihr Azure Stack Hub-System ausgewählt haben. Beispiel: Wenn die Region Redmond und der externe Domänenname contoso.com lautet, haben die DNS-Namen das Format prefix.redmond.contoso.com. Die prefix>-Werte werden von Microsoft vordefiniert, um den durch das Zertifikat geschützten Endpunkt zu beschreiben. Darüber hinaus hängen die prefix>-Werte der externen Infrastrukturendpunkte vom Azure Stack Hub-Dienst ab, der den spezifischen Endpunkt verwendet.

Für Produktionsumgebungen wird empfohlen, für jeden Endpunkt eigene Zertifikate zu generieren und in das entsprechende Verzeichnis zu kopieren. In Entwicklungsumgebungen können Zertifikate als einzelnes, in alle Verzeichnisse kopiertes Platzhalterzertifikat bereitgestellt werden, das alle Namespaces in den Feldern für Antragsteller und alternative Antragstellernamen (Subject Alternative Name, SAN) abdeckt. Ein einzelnes Zertifikat für alle Endpunkte und Dienste ist eine unsichere Methode und sollte daher nur in der Entwicklung verwendet werden. Wie bereits erwähnt, müssen für beide Optionen Platzhalterzertifikate für Endpunkte wie acs und Key Vault verwendet werden, wenn dies erforderlich sind.

Hinweis

Während der Bereitstellung müssen Sie Zertifikate in den Bereitstellungsordner kopieren, der dem Identitätsanbieter entspricht, für den Sie die Bereitstellung durchführen (Microsoft Entra ID oder AD FS). Wenn Sie ein einzelnes Zertifikat für alle Endpunkte verwenden, müssen Sie diese Zertifikatdatei, wie in den folgenden Tabellen aufgeführt, in jeden Bereitstellungsordner kopieren. Die Ordnerstruktur ist bereits im virtuellen Computer für die Bereitstellung unter folgendem Pfad festgelegt: C:\CloudDeployment\Setup\Certificates.

Bereitstellungsordner	Erforderlicher Zertifikatantragsteller und alternative Antragstellernamen	Bereich (pro Region)	Namespace der Unterdomäne
Öffentliches Portal	portal.<region>.<fqdn>	Portale	<region>.<fqdn>
Verwaltungsportal	adminportal.<region>.<fqdn>	Portale	<region>.<fqdn>
Azure Resource Manager (Öffentlich)	management.<region>.<fqdn>	Azure Resource Manager	<region>.<fqdn>
Azure Resource Manager (Verwaltung)	adminmanagement.<region>.<fqdn>	Azure Resource Manager	<region>.<fqdn>
ACSBlob	*.blob.<region>.<fqdn> (SSL-Platzhalterzertifikat)	Blob Storage	blob.<region>.<fqdn>
ACSTable	*.table.<region>.<fqdn> (SSL-Platzhalterzertifikat)	Table Storage	table.<region>.<fqdn>
ACSQueue	*.queue.<region>.<fqdn> (SSL-Platzhalterzertifikat)	Queue Storage	queue.<region>.<fqdn>
KeyVault	*.vault.<region>.<fqdn> (SSL-Platzhalterzertifikat)	Key Vault	vault.<region>.<fqdn>
KeyVaultInternal	*.adminvault.<region>.<fqdn> (SSL-Platzhalterzertifikat)	Interner Schlüsseltresor	adminvault.<region>.<fqdn>
Administratorerweiterungshost	*.adminhosting.<region>.<fqdn> (SSL-Platzhalterzertifikate)	Administratorerweiterungshost	adminhosting.<region>.<fqdn>
Öffentlicher Erweiterungshost	*.hosting.<region>.<fqdn> (SSL-Platzhalterzertifikate)	Öffentlicher Erweiterungshost	hosting.<region>.<fqdn>

Wenn Sie Azure Stack Hub mit dem Microsoft Entra Bereitstellungsmodus bereitstellen, müssen Sie nur die in der vorherigen Tabelle aufgeführten Zertifikate anfordern. Wenn Sie jedoch Azure Stack Hub mit dem AD FS-Bereitstellungsmodus bereitstellen, müssen Sie auch die in der folgenden Tabelle beschriebenen Zertifikate anfordern:

Bereitstellungsordner	Erforderlicher Zertifikatantragsteller und alternative Antragstellernamen	Bereich (pro Region)	Namespace der Unterdomäne
ADFS	adfs.region>.<fqdn> (SSL-Zertifikat)	ADFS	region>.<fqdn>
Graph	graph.region>.<fqdn> (SSL-Zertifikat)	Graph	region>.<fqdn>

Wichtig

Alle Zertifikate, die in diesem Abschnitt aufgeführt sind, müssen das gleiche Kennwort haben.

Optionale PaaS-Zertifikate

Wenn Sie die Azure Stack Hub-PaaS-Dienste (z. B. SQL, MySQL, App Service oder Event Hubs) bereitstellen möchten, nachdem Azure Stack Hub bereitgestellt und konfiguriert wurde, müssen Sie zusätzliche Zertifikate anfordern, um die Endpunkte der PaaS-Dienste abzudecken.

Wichtig

Die Zertifikate, die Sie für Ressourcenanbieter verwenden, müssen dieselbe Stammzertifizierungsstelle haben wie die Zertifikate, die für die globalen Azure Stack Hub-Endpunkte verwendet werden.

In der folgenden Tabelle sind die Endpunkte und Zertifikate beschrieben, die für Ressourcenanbieter erforderlich sind. Sie müssen diese Zertifikate nicht in den Azure Stack Hub-Bereitstellungsordner kopieren. Stattdessen stellen Sie diese Zertifikate während der Installation der Ressourcenanbieter bereit.

Bereich (pro Region)	Zertifikat	Erforderlicher Zertifikatantragsteller und alternative Antragstellernamen	Namespace der Unterdomäne
App Service	Webdatenverkehr: SSL-Standardzertifikat	*.appservice.region>.<fqdn> *.scm.appservice.region>.<fqdn> *.sso.appservice.region>.<fqdn> (SSL-Platzhalterzertifikat für mehrere Domänen1)	appservice.region>.<fqdn> scm.appservice.region>.<fqdn>
App Service	API	api.appservice.region>.<fqdn> (SSL-Zertifikat2)	appservice.region>.<fqdn> scm.appservice.region>.<fqdn>
App Service	FTP	ftp.appservice.region>.<fqdn> (SSL-Zertifikat2)	appservice.region>.<fqdn> scm.appservice.region>.<fqdn>
App Service	SSO	sso.appservice.region>.<fqdn> (SSL-Zertifikat2)	appservice.region>.<fqdn> scm.appservice.region>.<fqdn>
Event Hubs	SSL	*.eventhub.region>.<fqdn> (SSL-Platzhalterzertifikat)	eventhub.region>.<fqdn>
SQL, MySQL	SQL und MySQL	*.dbadapter.region>.<fqdn> (SSL-Platzhalterzertifikat)	dbadapter.region>.<fqdn>

¹ Erfordert ein Zertifikat mit Platzhaltern für mehrere alternative Antragstellernamen. Mehrere Platzhalter für alternative Antragstellernamen auf einem einzigen Zertifikat werden ggf. nicht von allen öffentlichen Zertifizierungsstellen unterstützt.

² Ein Platzhalterzertifikat des Typs *.appservice.region.<fqdn> kann nicht anstelle dieser drei Zertifikate (api.appservice.<, ftp.appservice.> und sso.appservice.<) verwendet werden. App Service erfordert explizit die Verwendung separater Zertifikate für diese Endpunkte.

Nächste Schritte

Erfahren Sie mehr zum Generieren von PKI-Zertifikaten für die Azure Stack Hub-Bereitstellung.