Wymagania dotyczące certyfikatów infrastruktury kluczy publicznych (PKI) usługi Azure Stack Hub
Azure Stack Hub ma sieć infrastruktury publicznej, która korzysta z zewnętrznych publicznych adresów IP przypisanych do ograniczonego zestawu usług Azure Stack Hub oraz ewentualnie do maszyn wirtualnych dzierżawców. Certyfikaty PKI z odpowiednimi nazwami DNS dla tych publicznych punktów końcowych infrastruktury usługi Azure Stack Hub są wymagane podczas wdrażania usługi Azure Stack Hub. Ten artykuł zawiera informacje o:
- 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.
Notatka
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, dodając ten certyfikat do lokalnego magazynu certyfikatów. W usłudze Azure Stack Hub nie ma przypinania ani filtrowania certyfikatów. SAN każdego certyfikatu serwera jest weryfikowany względem 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 dotyczące 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żywa się publicznego urzędu certyfikacji, musi zostać uwzględniony w podstawowym obrazie systemu operacyjnego w ramach Programu Zaufanych Urzędów Certyfikacji firmy Microsoft. Aby uzyskać pełną listę, zobacz Lista uczestników — Microsoft Trusted Root Program.
- Infrastruktura usługi Azure Stack Hub musi mieć dostęp sieciowy do lokalizacji listy odwołania certyfikatów urzędu certyfikacji (CRL) opublikowanej w certyfikacie. CRL musi być punktem końcowym HTTP. Uwaga: dla odłączonych wdrożeń, certyfikaty wystawione przez publiczny urząd certyfikacji (CA) nie są obsługiwane, jeśli punkt końcowy CRL nie jest dostępny. Aby uzyskać więcej informacji, zobacz: Funkcje, które są ograniczone lub niedostępne w przypadku wdrożeń bez połączenia.
- W przypadku rotacji certyfikatów w kompilacjach sprzed wersji 1903, certyfikaty muszą być wystawiane przez ten sam wewnętrzny urząd certyfikacji, który został użyty do podpisania certyfikatów dostarczonych przy wdrożeniu, lub przez dowolny z wymienionych wcześniej publicznych urzędów certyfikacji.
- W przypadku rotacji certyfikatów dla kompilacji 1903 i nowszych certyfikaty mogą być wystawiane przez dowolną organizację lub publiczną instytucję certyfikującą.
- 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żna użyć poszczególnych certyfikatów dla każdej z poniższych przestrzeni nazw, które są wymagane przez usługi Azure Stack Hub. Oba podejścia wymagają użycia symboli wieloznacznych w punktach końcowych, gdzie są one potrzebne, 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 być 3DES (to szyfrowanie jest domyślne podczas eksportowania z klienta systemu Windows 10 lub magazynu certyfikatów systemu Windows Server 2016).
- Pliki certyfikatu pfx muszą mieć wartość "Podpis cyfrowy" i "Szyfrowanie klucza" 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 literami 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 pojedynczy certyfikat SSL.
Notatka
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).
Notatka
Obecność urzędów certyfikacji pośredniczących w łańcuchu zaufania certyfikatu jest obsługiwana.
Obowiązkowe certyfikaty
W tabeli w tej sekcji opisano certyfikaty PKI publicznych punktów końcowych Azure Stack Hub wymagane zarówno dla wdrożeń Microsoft Entra ID, jak i AD FS. Wymagania dotyczące certyfikatów są grupowane 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.
Certyfikaty z odpowiednimi nazwami DNS dla każdego publicznego punktu końcowego infrastruktury usługi Azure Stack Hub są wymagane. Nazwa DNS każdego punktu końcowego jest wyrażona w formacie: <prefiks>.<region>.<fqdn>.
W przypadku wdrożenia wartości <regionu> i <fqdn> muszą być zgodne z nazwami regionów i domen zewnętrznych wybranych dla systemu usługi Azure Stack Hub. Na przykład jeśli region jest Redmond, a nazwa domeny zewnętrznej jest contoso.com, nazwy DNS będą miały format <prefiks>.redmond.contoso.com. Prefiksy <wartości> są przeznaczone przez firmę Microsoft do opisania punktu końcowego zabezpieczonego przez certyfikat. Ponadto wartości zewnętrznych punktów końcowych infrastruktury z prefiksu <> zależą od usługi Azure Stack Hub, która korzysta z 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 przypadku środowisk deweloperskich certyfikaty mogą być udostępniane jako pojedynczy certyfikat typu wildcard obejmujący wszystkie przestrzenie nazw w polach Podmiot i Alternatywna nazwa podmiotu (SAN), skopiowany do wszystkich katalogów. Pojedynczy certyfikat obejmujący wszystkie punkty końcowe i usługi jest podejściem niezabezpieczonym i dlatego jest wyłącznie do celów rozwojowych. Pamiętaj, że obie opcje wymagają używania certyfikatów wieloznacznych dla punktów końcowych, takich jak acs oraz Key Vault, w miejscach, gdzie są one wymagane.
Notatka
Podczas wdrażania należy skopiować certyfikaty do folderu wdrożenia, który odpowiada dostawcy tożsamości, którego wdrażasz (Microsoft Entra ID lub AD FS). Jeśli używasz pojedynczego certyfikatu dla wszystkich punktów końcowych, musisz skopiować ten plik certyfikatu do każdego folderu wdrożenia, jak opisano w poniższych tabelach. Struktura folderów jest wcześniej przygotowana w maszynie wirtualnej wdrożeniowej i można ją znaleźć pod adresem C:\CloudDeployment\Setup\Certificates.
| Folder do wdrażania | Wymagany temat certyfikatu oraz alternatywne nazwy tematu (SAN) | Zakres (na region) | Przestrzeń nazw poddomeny |
|---|---|---|---|
| Portal publiczny | portal.<region>.<fqdn> | Portale | <region>.<fqdn> |
| Portal administracyjny | adminportal.<region>.<fqdn> | Portale | <region>.<fqdn> |
| Usługa Azure Resource Manager — publiczna | zarządzanie.<region>.<fqdn> | Azure Resource Manager | <region>.<fqdn> |
| Administrator usługi Azure Resource Manager | adminmanagement.<region>.<fqdn> | Azure Resource Manager | <region>.<fqdn> |
| ACSBlob | *.blob.<region>.<fqdn> (Wieloznaczny certyfikat SSL) |
Blob Storage (przechowywanie obiektów) | Blob.<region>.<fqdn> |
| Tabela ACS | *.stół.<region>.><fqdn Certyfikat SSL typu Wildcard |
Przechowywanie tabel | stół.<region>.<fqdn> |
| ACSQueue | *.kolejka.<region>.<fqdn> (Wieloznaczny certyfikat SSL) |
Przechowywanie w kolejce | kolejka.<region>.<fqdn> |
| KeyVault | *.sklepienie.<region>.><fqdn Certyfikat SSL typu Wildcard |
Usługa Key Vault | sklepienie.<region>.<fqdn> |
| KeyVaultInternal | *.adminvault.<region>.<fqdn> (Certyfikat SSL typu wildcard) |
Wewnętrzny magazyn kluczy | adminvault.<region>.<> fqdn |
| Host rozszerzenia administratora | *.adminhosting.<region>.<fqdn> (wieloznaczne certyfikaty SSL) | Host rozszerzenia administratora | adminhosting.<region>.<fqdn> |
| Host rozszerzenia publicznego | *.hosting.<region>.<fqdn> (certyfikaty SSL typu wildcard) | Host rozszerzenia publicznego | gościnność.<region>.><fqdn |
W przypadku wdrażania usługi Azure Stack Hub przy użyciu trybu wdrażania entra firmy Microsoft wystarczy 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 do wdrożenia | Wymagany podmiot certyfikatu i alternatywne nazwy podmiotu (SAN) | Zakres (na region) | Przestrzeń nazw poddomeny |
|---|---|---|---|
| Usługi ADFS | adfs.<region>.<fqdn> (Certyfikat SSL) |
Usługi ADFS | <region>.<fqdn> |
| Wykres | wykres.<region>.<>fqdn (Certyfikat SSL) |
Wykres | <region>.<fqdn> |
Ważny
Wszystkie certyfikaty wymienione w tej sekcji muszą mieć to samo hasło.
Opcjonalne certyfikaty PaaS
Jeśli planujesz wdrożenie usług PaaS usługi Azure Stack Hub (takich jak SQL, MySQL, App Service lub Event Hubs) po wdrożeniu i skonfigurowaniu usługi Azure Stack Hub, musisz zażądać dodatkowych certyfikatów, aby obejmowały punkty końcowe usług PaaS.
Ważny
Certyfikaty używane dla dostawców zasobów muszą mieć ten sam urząd certyfikacji nadrzędny, co certyfikaty używane dla globalnych punktów końcowych 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 wdrażania 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 |
|---|---|---|---|
| Usługa Aplikacji | Domyślny certyfikat SSL dla ruchu internetowego | *.appservice.<region>.<fqdn> *.scm.appservice.<region>.<fqdn> *.sso.appservice.<region>.<fqdn> (Wielodomenowy certyfikat SSL wildcard1) |
appservice.<region>.<fqdn> scm.appservice.<region>.><fqdn |
| Usługa aplikacji (App Service) | API | api.appservice.<region>.<fqdn> (Certyfikat SSL2) |
appservice.<region>.<fqdn> scm.appservice.<region>.><fqdn |
| Usługa aplikacji | FTP | ftp.appservice.<region>.<fqdn> (Certyfikat SSL2) |
appservice.<region>.<fqdn> scm.appservice.<region>.><fqdn |
| Usługa Aplikacji | Jednokrotne logowanie | sso.appservice.<region>.><fqdn (Certyfikat SSL2) |
appservice.<region>.<fqdn> scm.appservice.<region>.><fqdn |
| Event Hubs | PROTOKÓŁ SSL | *.eventhub.<region>.<fqdn> Certyfikat typu wildcard SSL |
eventhub.<region>.<fqdn> |
| SQL, MySQL | SQL i MySQL | *.dbadapter.<region>.<fqdn> (Certyfikat SSL typu Wildcard) |
dbadapter.<region>.<fqdn> |
1 Wymaga jednego certyfikatu z wieloma alternatywnymi nazwami podmiotów z symbolami wieloznacznymi. Wiele wieloznacznych numerów SAN w jednym certyfikacie może nie być obsługiwanych przez wszystkie publiczne urzędy certyfikacji.
2 *.appservice.<region>.<certyfikat z wieloznacznikiem> fqdn nie może być używany zamiast tych trzech certyfikatów (api.appservice.<region>.<fqdn>, ftp.appservice.<region>.<fqdn>, i sso.appservice.<region>.<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.