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.
  • Beim Rotieren von Zertifikaten in Builds vor 1903 müssen diese entweder von der gleichen internen Zertifizierungsstelle stammen, die auch zum Signieren der bei der Bereitstellung angegebenen Zertifikate verwendet wurde, oder von einer der oben angegebenen öffentlichen Zertifizierungsstellen.
  • 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

Die Tabelle in diesem Abschnitt beschreibt die PKI-Zertifikate für öffentliche Azure Stack Hub-Endpunkte, die sowohl für Azure AD- als auch für AD FS-gestützte 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 zu dem Identitätsanbieter gehört, für den Sie die Bereitstellung ausführen (Azure AD 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 im Azure AD-Bereitstellungsmodus bereitstellen, müssen Sie nur die in der vorigen 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>

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

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