Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure Stack Hub verfügt über ein öffentliches Infrastrukturnetzwerk mit extern zugänglichen öffentlichen IP-Adressen, die einem kleinen Satz von Azure Stack Hub-Diensten und möglicherweise Mandanten-VMs zugewiesen sind. PKI-Zertifikate mit den entsprechenden DNS-Namen für diese öffentlichen Azure Stack Hub-Infrastrukturendpunkte sind während der Azure Stack Hub-Bereitstellung erforderlich. Dieser Artikel enthält Informationen zu Folgendem:
- Zertifikatanforderungen für Azure Stack Hub.
- Obligatorische Zertifikate, die für die Azure Stack Hub-Bereitstellung erforderlich sind.
- Optionale Zertifikate, die beim Bereitstellen von Ressourcenanbietern für Wert addiert werden müssen.
Hinweis
Azure Stack Hub verwendet standardmäßig auch Zertifikate, die von einer internen active Directory-integrierten Zertifizierungsstelle (CA) für die Authentifizierung zwischen den Knoten ausgestellt wurden. Um das Zertifikat zu überprüfen, vertrauen alle Azure Stack Hub-Infrastrukturcomputer dem Stammzertifikat der internen Zertifizierungsstelle, indem Sie dieses Zertifikat zum lokalen Zertifikatspeicher hinzufügen. Es gibt keine Anheftung oder Filterung von Zertifikaten im Azure Stack Hub. Das SAN jedes Serverzertifikats wird anhand des FQDN des Ziels überprüft. Die gesamte Vertrauenskette wird ebenfalls überprüft, zusammen mit dem Ablaufdatum des Zertifikats (standard TLS-Serverauthentifizierung ohne Zertifikat-Pinning).
Zertifikatanforderungen
In der folgenden Liste werden die allgemeinen Anforderungen für die Ausstellung, Sicherheit und Formatierung von Zertifikaten beschrieben:
- Zertifikate müssen von einer internen oder öffentlichen Zertifizierungsstelle ausgestellt werden. Wenn eine öffentliche Zertifizierungsstelle verwendet wird, muss sie im Basisbetriebssystemimage als Teil des Microsoft Trusted Root Authority Program enthalten sein. 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 getrennten Bereitstellungen werden zertifikate, die von einer öffentlichen Zertifizierungsstelle (Ca) ausgestellt wurden, nicht unterstützt, wenn auf den CRL-Endpunkt nicht zugegriffen werden kann. Weitere Informationen finden Sie unter Features, die in getrennten Bereitstellungen beeinträchtigt oder nicht verfügbar sind.
- Beim Drehen von Zertifikaten in Vorabversionen von 1903 müssen Zertifikate entweder von derselben internen Zertifizierungsstelle ausgestellt werden, die zum Signieren von Zertifikaten verwendet wird, die bei der Bereitstellung oder einer öffentlichen Zertifizierungsstelle von oben bereitgestellt werden.
- Beim Drehen von Zertifikaten für Builds 1903 und höher können Zertifikate von jeder unternehmens- oder öffentlichen Zertifizierungsstelle ausgestellt werden.
- Die Verwendung von selbstsignierten Zertifikaten wird nicht unterstützt.
- Für die Bereitstellung und Drehung können Sie entweder ein einzelnes Zertifikat verwenden, das alle Namenszeichen im Antragstellernamen und alternativen Antragstellernamen (Subject Alternative Name, SAN) des Zertifikats abdeckt. Alternativ können Sie einzelne Zertifikate für jeden der unten aufgeführten Namespaces verwenden, für die die Azure Stack Hub-Dienste erforderlich sind. Beide Ansätze erfordern die Verwendung von Wildcards für Endpunkte, bei denen sie erforderlich sind, z. B. KeyVault und KeyVaultInternal.
- Der Zertifikatsignaturalgorithmus sollte nicht SHA1 sein.
- Das Zertifikatformat muss PFX sein, da sowohl die öffentlichen als auch die privaten Schlüssel für die Azure Stack Hub-Installation erforderlich sind. Für den privaten Schlüssel muss das Schlüsselattribut des lokalen Computers festgelegt sein.
- Die PFX-Verschlüsselung muss 3DES sein (diese Verschlüsselung ist beim Exportieren aus einem Windows 10-Client oder Einem Windows Server 2016-Zertifikatspeicher standard).
- Die Pfx-Zertifikatdateien müssen den Wert "Digitale Signatur" und "KeyEncipherment" im Feld "Schlüsselverwendung" aufweisen.
- 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 an:" des Zertifikats darf nicht mit dem Feld "Ausgestellt von:" übereinstimmen.
- Die Kennwörter für alle Pfx-Zertifikatdateien müssen zum Zeitpunkt der Bereitstellung identisch sein.
- Das Kennwort für das Pfx-Zertifikat muss ein komplexes Kennwort sein. Notieren Sie sich dieses Kennwort, da Sie es als Bereitstellungsparameter verwenden. Das Kennwort muss die folgenden Anforderungen an die Kennwortkomplexität erfüllen:
- Eine Mindestlänge von acht Zeichen.
- Mindestens drei der folgenden Zeichen: Großbuchstaben, Kleinbuchstaben, Zahlen von 0 bis 9, Sonderzeichen, alphabetisches Zeichen, das nicht Groß- oder Kleinbuchstaben ist.
- Stellen Sie sicher, dass die Antragstellernamen und alternativen Antragstellernamen in der alternativen Antragstellernamenerweiterung (x509v3_config) übereinstimmen. Mit dem Feld "Alternativer Antragstellername" 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.
Beim Bereitstellen von Azure Stack Hub im getrennten Modus wird empfohlen, von einer Unternehmenszertifizierungsstelle ausgestellte Zertifikate zu verwenden. Dies ist wichtig, da Clients, die auf Azure Stack Hub-Endpunkte zugreifen, in der Lage sein müssen, die Zertifikatsperrliste (Certificate Revocation List, CRL) zu kontaktieren.
Hinweis
Das Vorhandensein von Vermittlerzertifizierungsstellen in der Vertrauenskette eines Zertifikats wird unterstützt.
Obligatorische Zertifikate
In der Tabelle in diesem Abschnitt werden die öffentlichen 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. Zertifikatanforderungen werden nach Bereich gruppiert, und die verwendeten Namespaces und die Zertifikate, die für jeden Namespace erforderlich sind. In der Tabelle wird auch der Ordner beschrieben, in dem Ihr Lösungsanbieter die verschiedenen Zertifikate pro öffentlichem Endpunkt kopiert.
Zertifikate mit den entsprechenden DNS-Namen für diese Endpunkte der öffentlichen Infrastruktur von Azure Stack Hub sind erforderlich. Der DNS-Name jedes Endpunkts wird im Format ausgedrückt: <Präfix>.<Region>.<fqdn>.
Für Ihre Bereitstellung müssen die <Werte für Region> und <Fqdn> mit den Regionen und externen Domänennamen übereinstimmen, die Sie für Ihr Azure Stack Hub-System ausgewählt haben. Wenn die Region beispielsweise "Redmond" ist und der externe Domänenname contoso.com ist, weisen die DNS-Namen das Formatpräfix< ".redmond.contoso.com" auf>. Die <Präfixwerte> werden von Microsoft vorkonfiguriert, um den vom Zertifikat gesicherten Endpunkt zu beschreiben. Darüber hinaus hängen die <Präfixwerte> der externen Infrastrukturendpunkte vom Azure Stack Hub-Dienst ab, der den jeweiligen Endpunkt verwendet.
Für Produktionsumgebungen wird empfohlen, für jeden Endpunkt eigene Zertifikate zu generieren und in das entsprechende Verzeichnis zu kopieren. Für Entwicklungsumgebungen können Zertifikate als einzelnes Wildcardzertifikat bereitgestellt werden, das alle Namespaces in den Feldern Subject and Subject Alternative Name (SAN) abdeckt, die in alle Verzeichnisse kopiert wurden. 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 bereitstellen (Microsoft Entra ID oder AD FS). Wenn Sie ein einzelnes Zertifikat für alle Endpunkte verwenden, müssen Sie diese Zertifikatdatei in jeden Bereitstellungsordner kopieren, wie in den folgenden Tabellen beschrieben. Die Ordnerstruktur ist im virtuellen Bereitstellungscomputer vorinstalliert und finden Sie unter: C:\CloudDeployment\Setup\Certificates.
| Bereitstellungsordner | Erforderlicher Zertifikatantragsteller und alternative Antragstellernamen | Bereich (pro Region) | Subdomänen-Namespace |
|---|---|---|---|
| Ö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-Zertifikat für Wildcard) |
Blob-Speicher | Blob.<Region>.<fqdn> |
| ACSTable | *.Tisch.<Region>.<fqdn> (SSL-Zertifikat für Wildcard) |
Tabellenspeicher | Tisch.<Region>.<fqdn> |
| ACSQueue | *.Schlange.<Region>.<fqdn> (SSL-Zertifikat für Wildcard) |
Wartespeicher | Schlange.<Region>.<fqdn> |
| KeyVault | *.Gewölbe.<Region>.<fqdn> (SSL-Zertifikat für Wildcard) |
Schlüsselspeicher (Key Vault) | Gewölbe.<Region>.<fqdn> |
| KeyVaultInternal | *.adminvault.<Region>.<fqdn> (SSL-Zertifikat für Wildcard) |
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 mithilfe des Microsoft Entra-Bereitstellungsmodus bereitstellen, müssen Sie nur die in der vorherigen Tabelle aufgeführten Zertifikate anfordern. Wenn Sie Azure Stack Hub jedoch im 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) | Subdomänen-Namespace |
|---|---|---|---|
| ADFS | adfs. <Region>.<fqdn> (SSL-Zertifikat) |
ADFS | <Region>.<fqdn> |
| Graph | Graph. <Region>.<fqdn> (SSL-Zertifikat) |
Graph | <Region>.<fqdn> |
Von Bedeutung
Alle in diesem Abschnitt aufgeführten Zertifikate müssen über dasselbe Kennwort verfügen.
Optionale PaaS-Zertifikate
Wenn Sie planen, Azure Stack Hub PaaS-Dienste (z. B. SQL, MySQL, App Service oder Event Hubs) bereitzustellen, nachdem Azure Stack Hub bereitgestellt und konfiguriert wurde, müssen Sie zusätzliche Zertifikate anfordern, um die Endpunkte der PaaS-Dienste abzudecken.
Von Bedeutung
Die Zertifikate, die Sie für Ressourcenanbieter verwenden, müssen über dieselbe Stammzertifizierungsstelle verfügen wie die Zertifikate, die für die globalen Azure Stack Hub-Endpunkte verwendet werden.
In der folgenden Tabelle werden 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 des Ressourcenanbieters bereit.
| Bereich (pro Region) | Zertifikat | Erforderliche Zertifikatsbetreffer und alternative Antragstellernamen (SANs) | Subdomänen-Namespace |
|---|---|---|---|
| App-Dienst | Standard-SSL-Zertifikat für Webdatenverkehr | *.appservice. <Region>.<fqdn> *.scm.appservice. <Region>.<fqdn> *.sso.appservice. <Region>.<fqdn> (Multi Domain Wildcard SSL Certificate1) |
appservice. <Region>.<fqdn> scm.appservice. <Region>.<fqdn> |
| App-Dienst | Programmierschnittstelle (API) | api.appservice. <Region>.<fqdn> (SSL-Zertifikat2) |
appservice. <Region>.<fqdn> scm.appservice. <Region>.<fqdn> |
| App-Dienst | FTP | ftp.appservice. <Region>.<fqdn> (SSL-Zertifikat2) |
appservice. <Region>.<fqdn> scm.appservice. <Region>.<fqdn> |
| App-Dienst | Single Sign-On (SSO) | sso.appservice. <Region>.<fqdn> (SSL-Zertifikat2) |
appservice. <Region>.<fqdn> scm.appservice. <Region>.<fqdn> |
| Ereignis-Hubs | SSL | *.eventhub. <Region>.<fqdn> (SSL-Zertifikat für Wildcard) |
eventhub. <Region>.<fqdn> |
| SQL, MySQL | SQL und MySQL | *.dbadapter. <Region>.<fqdn> (SSL-Zertifikat für Wildcard) |
dbadapter. <Region>.<fqdn> |
1 Erfordert ein Zertifikat mit mehreren alternativen Antragstellernamen mit mehreren Wildcard-Antragstellernamen. Mehrere Wildcard-SANs für ein einzelnes Zertifikat werden möglicherweise nicht von allen öffentlichen Zertifizierungsstellen unterstützt.
2 A *.appservice. <Region>.<fqdn-Platzhalterzertifikat> kann nicht anstelle dieser drei Zertifikate (api.appservice) verwendet werden.<Region>.<fqdn>, ftp.appservice. <Region>.<fqdn> und sso.appservice. <Region>.<fqdn>. Appservice erfordert explizit die Verwendung separater Zertifikate für diese Endpunkte.
Nächste Schritte
Erfahren Sie, wie Sie PKI-Zertifikate für die Azure Stack Hub-Bereitstellung generieren.