Wymagania dotyczące certyfikatu infrastruktury kluczy publicznych (PKI) usługi Azure Stack Hub

Usługa Azure Stack Hub ma sieć infrastruktury publicznej korzystającą z zewnętrznych publicznych adresów IP przypisanych do małego zestawu usług Azure Stack Hub i ewentualnie maszyn wirtualnych dzierżawcy. Certyfikaty PKI z odpowiednimi nazwami DNS dla tych punktów końcowych infrastruktury publicznej usługi Azure Stack Hub są wymagane podczas wdrażania usługi Azure Stack Hub. Ten artykuł zawiera informacje na temat:

• Wymagania dotyczące certyfikatów dla usługi Azure Stack Hub.
• Obowiązkowe certyfikaty wymagane do wdrożenia usługi Azure Stack Hub.
• Opcjonalne certyfikaty wymagane podczas wdrażania dostawców zasobów dodawania wartości.

Uwaga

Usługa Azure Stack Hub domyślnie używa również certyfikatów wystawionych z wewnętrznego urzędu certyfikacji zintegrowanego z usługą Active Directory do uwierzytelniania między węzłami. Aby zweryfikować certyfikat, wszystkie maszyny infrastruktury usługi Azure Stack Hub ufają certyfikatowi głównemu wewnętrznego urzędu certyfikacji przez dodanie tego certyfikatu do lokalnego magazynu certyfikatów. W usłudze Azure Stack Hub nie ma przypinania ani filtrowania certyfikatów. Sieć SAN każdego certyfikatu serwera jest weryfikowana względem nazwy FQDN obiektu docelowego. Cały łańcuch zaufania jest również weryfikowany wraz z datą wygaśnięcia certyfikatu (standardowe uwierzytelnianie serwera TLS bez przypinania certyfikatu).

Wymagania certyfikatu

Poniższa lista zawiera ogólne wymagania dotyczące wystawiania certyfikatów, zabezpieczeń i formatowania:

• Certyfikaty muszą być wystawiane z wewnętrznego urzędu certyfikacji lub publicznego urzędu certyfikacji. Jeśli używany jest publiczny urząd certyfikacji, musi on zostać uwzględniony w podstawowym obrazie systemu operacyjnego w ramach programu zaufanego urzędu głównego firmy Microsoft. Aby uzyskać pełną listę, zobacz Lista uczestników — zaufany program główny firmy Microsoft.
• Infrastruktura usługi Azure Stack Hub musi mieć dostęp sieciowy do lokalizacji listy odwołania certyfikatów (CRL) urzędu certyfikacji opublikowanej w certyfikacie. Ta lista CRL musi być punktem końcowym HTTP. Uwaga: w przypadku wdrożeń bez połączenia certyfikaty wystawione przez publiczny urząd certyfikacji nie są obsługiwane, jeśli punkt końcowy listy CRL jest niedostępny. Aby uzyskać więcej informacji , zobacz Funkcje, które są niepełnosprawne lub niedostępne w rozłączonych wdrożeniach.

• W przypadku rotacji certyfikatów dla kompilacji 1903 i nowszych certyfikaty mogą być wystawiane przez dowolne przedsiębiorstwo lub publiczny urząd certyfikacji.

• Korzystanie z certyfikatów z podpisem własnym nie jest obsługiwane.
• W przypadku wdrażania i rotacji można użyć jednego certyfikatu obejmującego wszystkie przestrzenie nazw w nazwie podmiotu certyfikatu i alternatywnej nazwie podmiotu (SAN). Alternatywnie możesz użyć poszczególnych certyfikatów dla każdej z poniższych przestrzeni nazw, które mają być używane przez usługi Azure Stack Hub, które mają być wymagane. Obie metody wymagają użycia symboli wieloznacznych dla punktów końcowych, w których są wymagane, takich jak KeyVault i KeyVaultInternal.
• Algorytm podpisu certyfikatu nie powinien być algorytmem SHA1.
• Format certyfikatu musi mieć format PFX, ponieważ zarówno klucze publiczne, jak i prywatne są wymagane do instalacji usługi Azure Stack Hub. Klucz prywatny musi mieć ustawiony atrybut klucza komputera lokalnego.
• Szyfrowanie PFX musi mieć format 3DES (to szyfrowanie jest domyślne podczas eksportowania z klienta Windows 10 lub magazynu certyfikatów Windows Server 2016).
• Pliki pfx certyfikatu muszą mieć wartość "Podpis cyfrowy" i "KeyEncipherment" w polu "Użycie klucza".
• Pliki pfx certyfikatu muszą mieć wartości "Uwierzytelnianie serwera (1.3.6.1.5.5.7.3.1)" i "Uwierzytelnianie klienta (1.3.6.1.5.5.7.3.2)" w polu "Rozszerzone użycie klucza".
• Pole "Wystawione do:" certyfikatu nie może być takie samo jak pole "Wystawione przez:".
• Hasła do wszystkich plików pfx certyfikatu muszą być takie same w czasie wdrażania.
• Hasło do certyfikatu pfx musi być złożonym hasłem. Zanotuj to hasło, ponieważ użyjesz go jako parametru wdrożenia. Hasło musi spełniać następujące wymagania dotyczące złożoności hasła:
  • Minimalna długość ośmiu znaków.
  • Co najmniej trzy z następujących znaków: wielkie litery, małe litery, cyfry od 0 do 9, znaki specjalne, znak alfabetyczny, który nie jest wielkimi lub małymi literami.
• Upewnij się, że nazwy podmiotów i alternatywne nazwy podmiotów w rozszerzeniu alternatywnej nazwy podmiotu (x509v3_config) są zgodne. Pole alternatywnej nazwy podmiotu umożliwia określenie dodatkowych nazw hostów (witryn internetowych, adresów IP, nazw pospolitych) chronionych przez jeden certyfikat SSL.

Uwaga

Certyfikaty z podpisem własnym nie są obsługiwane.
Podczas wdrażania usługi Azure Stack Hub w trybie rozłączenia zaleca się używanie certyfikatów wystawionych przez urząd certyfikacji przedsiębiorstwa. Jest to ważne, ponieważ klienci, którzy uzyskują dostęp do punktów końcowych usługi Azure Stack Hub, muszą mieć możliwość skontaktowania się z listą odwołania certyfikatów (CRL).

Uwaga

Obecność pośredniczących urzędów certyfikacji w łańcuchu zaufania certyfikatu jest obsługiwana.

Wymagane certyfikaty

W tabeli w tej sekcji opisano certyfikaty infrastruktury kluczy publicznych publicznych punktów końcowych usługi Azure Stack Hub, które są wymagane zarówno dla Microsoft Entra identyfikatora, jak i wdrożeń usługi AD FS w usłudze Azure Stack Hub. Wymagania dotyczące certyfikatów są pogrupowane według obszaru, a używane przestrzenie nazw i certyfikaty wymagane dla każdej przestrzeni nazw. W tabeli opisano również folder, w którym dostawca rozwiązania kopiuje różne certyfikaty na publiczny punkt końcowy.

Wymagane są certyfikaty z odpowiednimi nazwami DNS dla każdego punktu końcowego infrastruktury publicznej usługi Azure Stack Hub. Nazwa DNS każdego punktu końcowego jest wyrażona w formacie: <prefiks>.<region>.<fqdn>.

W przypadku wdrożenia <wartości regionów> i <nazw fqdn> muszą być zgodne z regionem i nazwami domen zewnętrznych, które wybrano dla systemu usługi Azure Stack Hub. Jeśli na przykład region to Redmond, a nazwa domeny zewnętrznej jest contoso.com, nazwy DNS będą miały prefiks> formatu.redmond.contoso.com<. Wartości prefiksów<> są wstępnie określone przez firmę Microsoft w celu opisania punktu końcowego zabezpieczonego przez certyfikat. Ponadto <wartości prefiksów> zewnętrznych punktów końcowych infrastruktury zależą od usługi Azure Stack Hub, która używa określonego punktu końcowego.

W środowiskach produkcyjnych zalecamy wygenerowanie poszczególnych certyfikatów dla każdego punktu końcowego i skopiowanie ich do odpowiedniego katalogu. W środowiskach deweloperskich certyfikaty mogą być udostępniane jako pojedynczy certyfikat wieloznaczny obejmujący wszystkie przestrzenie nazw w polach Podmiot i Alternatywna nazwa podmiotu (SAN) skopiowane do wszystkich katalogów. Pojedynczy certyfikat obejmujący wszystkie punkty końcowe i usługi jest stanem niezabezpieczonym i dlatego tylko do programowania. Pamiętaj, że obie opcje wymagają używania certyfikatów wieloznacznych dla punktów końcowych, takich jak acs i Key Vault tam, gdzie są wymagane.

Uwaga

Podczas wdrażania należy skopiować certyfikaty do folderu wdrożenia zgodnego z wdrażaną dostawcą tożsamości (Microsoft Entra identyfikatorem lub usługami AD FS). Jeśli używasz jednego certyfikatu dla wszystkich punktów końcowych, musisz skopiować ten plik certyfikatu do każdego folderu wdrożenia zgodnie z opisem w poniższych tabelach. Struktura folderów jest wstępnie wbudowana w maszynę wirtualną wdrożenia i znajduje się w folderze C:\CloudDeployment\Setup\Certificates.

Folder wdrożenia	Wymagany podmiot certyfikatu i alternatywne nazwy podmiotu (SAN)	Zakres (na region)	Przestrzeń nazw poddomeny
Portal publiczny	Portal.<region>.<Fqdn>	Portale	<region>.<Fqdn>
Portal administracyjny	adminportal.<region>.<Fqdn>	Portale	<region>.<Fqdn>
Azure Resource Manager publiczna	Zarządzania.<region>.<Fqdn>	Azure Resource Manager	<region>.<Fqdn>
Azure Resource Manager Administracja	adminmanagement.<region>.<Fqdn>	Azure Resource Manager	<region>.<Fqdn>
ACSBlob	*.Blob.<region>.<Fqdn> (Certyfikat SSL z symbolami wieloznacznymi)	Blob Storage	Blob.<region>.<Fqdn>
ACSTable	*.Tabeli.<region>.<Fqdn> (Certyfikat SSL z symbolami wieloznacznymi)	Table Storage	Tabeli.<region>.<Fqdn>
ACSQueue	*.Kolejki.<region>.<Fqdn> (Certyfikat SSL z symbolami wieloznacznymi)	Queue Storage	Kolejki.<region>.<Fqdn>
KeyVault	*.Vault.<region>.<Fqdn> (Certyfikat SSL z symbolami wieloznacznymi)	Key Vault	Vault.<region>.<Fqdn>
KeyVaultInternal	*.adminvault.<region>.<Fqdn> (Certyfikat SSL z symbolami wieloznacznymi)	Wewnętrzna usługa Keyvault	adminvault.<region>.<Fqdn>
host rozszerzenia Administracja	*.adminhosting.<region>.<fqdn> (certyfikaty SSL z symbolami wieloznacznymi)	host rozszerzenia Administracja	adminhosting.<region>.<Fqdn>
Host rozszerzenia publicznego	*.Hosting.<region>.<fqdn> (certyfikaty SSL z symbolami wieloznacznymi)	Host rozszerzenia publicznego	Hosting.<region>.<Fqdn>

Jeśli wdrożysz usługę Azure Stack Hub przy użyciu trybu wdrażania Microsoft Entra, musisz zażądać certyfikatów wymienionych w poprzedniej tabeli. Jeśli jednak wdrożysz usługę Azure Stack Hub przy użyciu trybu wdrażania usług AD FS, musisz również zażądać certyfikatów opisanych w poniższej tabeli:

Folder wdrożenia	Wymagany podmiot certyfikatu i alternatywne nazwy podmiotu (SAN)	Zakres (na region)	Przestrzeń nazw poddomeny
ADFS	Programu adfs. <region>.<Fqdn> (Certyfikat SSL)	ADFS	<region>.<Fqdn>
Graph	Wykres. <region>.<Fqdn> (Certyfikat SSL)	Graph	<region>.<Fqdn>

Ważne

Wszystkie certyfikaty wymienione w tej sekcji muszą mieć to samo hasło.

Opcjonalne certyfikaty PaaS

Jeśli planujesz wdrożyć usługi PaaS w usłudze Azure Stack Hub (takie jak SQL, MySQL, App Service lub Event Hubs) po wdrożeniu i skonfigurowaniu usługi Azure Stack Hub, musisz zażądać dodatkowych certyfikatów w celu pokrycia punktów końcowych usług PaaS.

Ważne

Certyfikaty używane dla dostawców zasobów muszą mieć ten sam urząd główny co certyfikaty używane dla globalnych punktów końcowych usługi Azure Stack Hub.

W poniższej tabeli opisano punkty końcowe i certyfikaty wymagane dla dostawców zasobów. Nie musisz kopiować tych certyfikatów do folderu wdrożenia usługi Azure Stack Hub. Zamiast tego należy podać te certyfikaty podczas instalacji dostawcy zasobów.

Zakres (na region)	Certyfikat	Wymagany podmiot certyfikatu i alternatywne nazwy podmiotu (SAN)	Przestrzeń nazw poddomeny
App Service	Domyślny certyfikat SSL ruchu internetowego	*.appservice. <region>.<Fqdn> *.scm.appservice. <region>.<Fqdn> *.sso.appservice. <region>.<Fqdn> (Wielodomenowy certyfikat SSL1)	appservice. <region>.<Fqdn> scm.appservice. <region>.<Fqdn>
App Service	interfejs API	api.appservice. <region>.<Fqdn> (Certyfikat SSL2)	appservice. <region>.<Fqdn> scm.appservice. <region>.<Fqdn>
App Service	FTP	ftp.appservice. <region>.<Fqdn> (Certyfikat SSL2)	appservice. <region>.<Fqdn> scm.appservice. <region>.<Fqdn>
App Service	Logowanie jednokrotne	sso.appservice. <region>.<Fqdn> (Certyfikat SSL2)	appservice. <region>.<Fqdn> scm.appservice. <region>.<Fqdn>
Event Hubs	Protokół SSL	*.eventhub. <region>.<Fqdn> (Certyfikat SSL z symbolami wieloznacznymi)	eventhub. <region>.<Fqdn>
SQL, MySQL	SQL i MySQL	*.dbadapter. <region>.<Fqdn> (Certyfikat SSL z symbolami wieloznacznymi)	dbadapter. <region>.<Fqdn>

¹ Wymaga jednego certyfikatu z wieloma alternatywnymi nazwami podmiotów z symbolami wieloznacznymi. Wiele sieci SAN z symbolami wieloznacznymi w jednym certyfikacie może nie być obsługiwane przez wszystkie publiczne urzędy certyfikacji.

² A *.appservice. <region>.<Nie można użyć certyfikatu wieloznacznych nazw fqdn> zamiast tych trzech certyfikatów (api.appservice).<region>.<fqdn>, ftp.appservice. <region>.<fqdn> i sso.appservice. <region>.<nazwa fqdn>. Usługa Appservice jawnie wymaga użycia oddzielnych certyfikatów dla tych punktów końcowych.

Następne kroki

Dowiedz się, jak wygenerować certyfikaty PKI dla wdrożenia usługi Azure Stack Hub.