Udostępnij przez

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

Domyślnie usługa Azure Stack Hub 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. 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. W przypadku wdrożeń bez połączenia, jeśli punkt końcowy listy CRL jest niedostępny, certyfikaty wystawione przez publiczny urząd certyfikacji nie są obsługiwane. Aby uzyskać więcej informacji, zobacz Funkcje, które są niedowidzące lub niedostępne we wdrożeniach 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ą.
  • Certyfikaty z podpisem własnym nie są 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)" 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żywasz 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ść pośredniczących urzędów certyfikacji 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 <prefix>.<region>.<fqdn>.

W przypadku wdrożenia <region> wartości i <fqdn> muszą być zgodne z regionem i nazwami domen zewnętrznych wybranych 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 mają format <prefix>.redmond.contoso.com. Wartości <prefix> są zarezerwowane przez firmę Microsoft w celu opisania punktu końcowego zabezpieczonego przez certyfikat. Ponadto <prefix> wartości punktów końcowych infrastruktury zewnętrznej 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 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 stanem niezabezpieczonym i dlatego przeznaczony 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, w których są 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 wstępnie wbudowana w maszynę wirtualną wdrożenia i znajduje się w katalogu 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 management.<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>
(Certyfikat SSL z symbolami wieloznacznymi)		 Magazyn obiektów blob blob.<region>.<fqdn>
Tabela ACS *.table.<region>.<fqdn>
(Certyfikat SSL z symbolami wieloznacznymi)		 Magazyn tabel table.<region>.<fqdn>
ACSQueue *.queue.<region>.<fqdn>
(Certyfikat SSL z symbolami wieloznacznymi)		 Magazyn kolejek queue.<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ętrzny magazyn kluczy adminvault.<region>.<fqdn>
Host rozszerzenia administratora *.adminhosting.<region>.<fqdn> (Certyfikaty SSL z symbolami wieloznacznymi) Host rozszerzenia administratora adminhosting.<region>.<fqdn>
Host rozszerzenia publicznego *.hosting.<region>.<fqdn> (Certyfikaty SSL z symbolami wieloznacznymi) Host rozszerzenia publicznego hosting.<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. W przypadku wdrażania usługi Azure Stack Hub przy użyciu trybu wdrażania usług AD FS należy również zażądać certyfikatów opisanych w poniższej tabeli:

Folder do wdrażania Wymagany temat certyfikatu oraz alternatywne nazwy tematu (SAN) Zakres (na region) Przestrzeń nazw poddomeny
ADFS adfs.<region>.<fqdn>
(Certyfikat SSL)		 AD FS <region>.<fqdn>
Graph graph.<region>.<fqdn>
(Certyfikat SSL)		 Graph <region>.<fqdn>

Ważny

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

Opcjonalne certyfikaty PaaS

Jeśli planujesz wdrożyć usługi PaaS usługi 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, 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
App Service 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>
App Service 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>
Centra zdarzeń SSL *.eventhub.<region>.<fqdn>
(Wieloznaczny certyfikat SSL)		 eventhub.<region>.<fqdn>
SQL, MySQL SQL i MySQL *.dbadapter.<region>.<fqdn>
(Wieloznaczny certyfikat SSL)		 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>.<fqdn> Certyfikat wieloznaczny 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.

  • Last updated on