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 w kompilacjach przed 1903 certyfikaty muszą być wystawiane z tego samego wewnętrznego urzędu certyfikacji używanego do podpisywania certyfikatów dostarczonych we wdrożeniu lub dowolnego publicznego urzędu certyfikacji z powyższego.
- 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> |
1 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.
2 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.