Certyfikaty i środowisko App Service Environment w wersji 2
Ważne
Ten artykuł dotyczy środowiska App Service Environment w wersji 2, który jest używany z planami izolowanej usługi App Service. Środowisko App Service Environment w wersji 1 i v2 jest wycofyzowane od 31 sierpnia 2024 r. Jest dostępna nowa wersja środowiska App Service Environment, która jest łatwiejsza do użycia i działa w bardziej wydajnej infrastrukturze. Aby dowiedzieć się więcej o nowej wersji, zacznij od wprowadzenia do środowiska App Service Environment. Jeśli obecnie używasz środowiska App Service Environment w wersji 1, wykonaj kroki opisane w tym artykule , aby przeprowadzić migrację do nowej wersji.
Od 31 sierpnia 2024 r. umowa dotycząca poziomu usług (SLA) i środki na usługi nie mają już zastosowania do obciążeń środowiska App Service Environment w wersji 1 i w wersji 2, które nadal znajdują się w środowisku produkcyjnym, ponieważ są wycofane produkty. Rozpoczęto likwidowanie sprzętu środowiska App Service Environment w wersji 1 i 2. Może to mieć wpływ na dostępność i wydajność aplikacji i danych.
Musisz natychmiast ukończyć migrację do środowiska App Service Environment w wersji 3 lub usunąć aplikacje i zasoby. Podejmiemy próbę automatycznej migracji wszystkich pozostałych środowisk App Service Environment w wersji 1 i 2 w oparciu o najlepsze rozwiązanie przy użyciu funkcji migracji w miejscu, ale firma Microsoft nie udziela żadnych oświadczeń ani gwarancji dotyczących dostępności aplikacji po migracji automatycznej. Może być konieczne wykonanie ręcznej konfiguracji w celu ukończenia migracji i zoptymalizowania wybranej jednostki SKU planu usługi App Service w celu spełnienia Twoich potrzeb. Jeśli automatyczna migracja nie jest wykonalna, zasoby i skojarzone dane aplikacji zostaną usunięte. Zdecydowanie zachęcamy do podjęcia działań, aby uniknąć jednego z tych ekstremalnych scenariuszy.
Jeśli potrzebujesz dodatkowego czasu, możemy zaoferować jednorazowy 30-dniowy okres prolongaty umożliwiający ukończenie migracji. Aby uzyskać więcej informacji i zażądać tego okresu prolongaty, zapoznaj się z omówieniem okresu prolongaty, a następnie przejdź do witryny Azure Portal i odwiedź blok Migracja dla każdego środowiska App Service Environment.
Aby uzyskać najbardziej aktualne informacje na temat wycofania środowiska App Service Environment w wersji 1/2, zobacz aktualizację wycofania środowiska App Service Environment w wersji 1 i 2.
Środowisko App Service Environment (ASE) to wdrożenie usługi aplikacja systemu Azure, która działa w ramach usługi Azure Virtual Network(VNet). Można go wdrożyć za pomocą internetowego punktu końcowego aplikacji lub punktu końcowego aplikacji, który znajduje się w sieci wirtualnej. W przypadku wdrożenia środowiska ASE z dostępnym przez Internet punktem końcowym wdrożenie jest nazywane zewnętrznym ase. W przypadku wdrożenia środowiska ASE z punktem końcowym w sieci wirtualnej wdrożenie to jest nazywane środowiskom ASE z wewnętrznym modułem równoważenia obciążenia. Więcej informacji na temat środowiska ASE z wewnętrznym modułem równoważenia obciążenia można dowiedzieć się z dokumentu Tworzenie środowiska ASE z wewnętrznym modułem równoważenia obciążenia i używanie go.
AsE to pojedynczy system dzierżawy. Ponieważ jest to jedna dzierżawa, istnieją pewne funkcje dostępne tylko w środowisku ASE, które nie są dostępne w wielodostępnym usłudze App Service.
Certyfikaty środowiska ASE z wewnętrznym modułem równoważenia obciążenia
Jeśli używasz zewnętrznego środowiska ASE, aplikacje są osiągane pod <adresem appname>.<asename.p.azurewebsites.net>. Domyślnie wszystkie środowiska ASE, nawet środowiska ASE z wewnętrznym modułem równoważenia obciążenia, są tworzone przy użyciu certyfikatów, które są zgodne z tym formatem. Po utworzeniu środowiska ASE z wewnętrznym modułem równoważenia obciążenia aplikacje są osiągane na podstawie nazwy domeny określonej podczas tworzenia środowiska ASE z wewnętrznym modułem równoważenia obciążenia. Aby aplikacje obsługiwały protokół TLS, należy przekazać certyfikaty. Uzyskaj prawidłowy certyfikat TLS/SSL przy użyciu wewnętrznych urzędów certyfikacji, zakupu certyfikatu od zewnętrznego wystawcy lub certyfikatu z podpisem własnym.
Istnieją dwie opcje konfigurowania certyfikatów przy użyciu środowiska ASE z wewnętrznym modułem równoważenia obciążenia. Możesz ustawić domyślny certyfikat wieloznaczny dla środowiska ASE z wewnętrznym modułem równoważenia obciążenia lub ustawić certyfikaty w poszczególnych aplikacjach internetowych w środowisku ASE. Niezależnie od wybranego wyboru należy prawidłowo skonfigurować następujące atrybuty certyfikatu:
- Temat: Ten atrybut musi być ustawiony na *.[ your-root-domain-here] dla wieloznacznych certyfikatu środowiska ASE z wewnętrznym modułem równoważenia obciążenia. Jeśli tworzysz certyfikat dla aplikacji, powinien to być [appname]. [your-root-domain-here]
- Alternatywna nazwa podmiotu: ten atrybut musi zawierać oba .[ your-root-domain-here] and.scm.[ your-root-domain-here] dla certyfikatu środowiska ASE z wieloznacznymi modułami równoważenia obciążenia. Jeśli tworzysz certyfikat dla aplikacji, powinien to być [appname]. [your-root-domain-here] i [appname].scm. [your-root-domain-here].
Jako trzeci wariant możesz utworzyć certyfikat środowiska ASE z wewnętrznym modułem równoważenia obciążenia, który zawiera wszystkie nazwy poszczególnych aplikacji w sieci SAN certyfikatu, zamiast używać odwołania wieloznakowego. Problem z tą metodą polega na tym, że musisz znać z góry nazwy aplikacji, które są wkładane do środowiska ASE, lub musisz zachować aktualizację certyfikatu środowiska ASE z wewnętrznym modułem równoważenia obciążenia.
Przekazywanie certyfikatu do środowiska ASE z wewnętrznym modułem równoważenia obciążenia
Po utworzeniu środowiska ASE z wewnętrznym modułem równoważenia obciążenia w portalu należy ustawić certyfikat dla środowiska ASE z wewnętrznym modułem równoważenia obciążenia. Dopóki certyfikat nie zostanie ustawiony, ase będzie wyświetlać transparent, że certyfikat nie został ustawiony.
Przekazany certyfikat musi być plikiem pfx. Po przekazaniu certyfikatu występuje opóźnienie czasu około 20 minut przed zastosowaniem certyfikatu.
Nie można utworzyć środowiska ASE i przekazać certyfikatu jako jednej akcji w portalu, a nawet w jednym szablonie. Jako osobną akcję możesz przekazać certyfikat przy użyciu szablonu zgodnie z opisem w dokumencie Tworzenie środowiska ASE z szablonu .
Jeśli chcesz szybko utworzyć certyfikat z podpisem własnym na potrzeby testowania, możesz użyć następującego fragmentu programu PowerShell:
$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"
$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText
$fileName = "exportedcert.pfx"
Export-PfxCertificate -cert $certThumbprint -FilePath $fileName -Password $password
Podczas tworzenia certyfikatu z podpisem własnym należy upewnić się, że nazwa podmiotu ma format CN={ASE_NAME_HERE}_InternalLoadBalancingASE.
Certyfikaty aplikacji
Aplikacje hostowane w środowisku ASE mogą korzystać z funkcji certyfikatów skoncentrowanych na aplikacji, które są dostępne w wielodostępnej usłudze App Service. Te funkcje obejmują:
- Certyfikaty SNI
- Protokół SSL oparty na protokole IP, który jest obsługiwany tylko w przypadku zewnętrznego środowiska ASE. Usługa ASE z wewnętrznym modułem równoważenia obciążenia nie obsługuje protokołu SSL opartego na protokole IP.
- Certyfikaty hostowane w usłudze KeyVault
Instrukcje dotyczące przekazywania tych certyfikatów i zarządzania nimi są dostępne w artykule Dodawanie certyfikatu TLS/SSL w usłudze aplikacja systemu Azure. Jeśli po prostu konfigurujesz certyfikaty w celu dopasowania niestandardowej nazwy domeny przypisanej do aplikacji internetowej, te instrukcje będą wystarczające. Jeśli przekazujesz certyfikat dla aplikacji internetowej środowiska ASE z wewnętrznym modułem równoważenia obciążenia z domyślną nazwą domeny, określ witrynę scm w sieci SAN certyfikatu zgodnie z wcześniejszym opisem.
Ustawienia protokołu TLS
Ustawienie PROTOKOŁU TLS można skonfigurować na poziomie aplikacji.
Certyfikat klienta prywatnego
Typowym przypadkiem użycia jest skonfigurowanie aplikacji jako klienta w modelu klient-serwer. W przypadku zabezpieczenia serwera przy użyciu certyfikatu prywatnego urzędu certyfikacji należy przekazać certyfikat klienta do aplikacji. Poniższe instrukcje spowodują załadowanie certyfikatów do magazynu zaufania procesów roboczych, na których działa aplikacja. Jeśli załadujesz certyfikat do jednej aplikacji, możesz użyć go z innymi aplikacjami w tym samym planie usługi App Service bez ponownego przekazania certyfikatu.
Aby przekazać certyfikat do aplikacji w środowisku ASE:
- Wygeneruj plik .cer dla certyfikatu.
- Przejdź do aplikacji, która wymaga certyfikatu w witrynie Azure Portal
- Przejdź do pozycji Ustawienia protokołu SSL w aplikacji. Kliknij pozycję Przekaż certyfikat. Wybierz pozycję Publiczna. Wybierz pozycję Komputer lokalny. Podaj nazwę. Przeglądaj i wybierz plik .cer . Wybierz pozycję Przekaż.
- Skopiuj odcisk palca.
- Przejdź do pozycji Ustawienia aplikacji. Utwórz ustawienie aplikacji WEBSITE_LOAD_ROOT_CERTIFICATES z odciskiem palca jako wartością. Jeśli masz wiele certyfikatów, możesz umieścić je w tym samym ustawieniu oddzielonym przecinkami i bez białych znaków, takich jak
84EC242A4EC7957817B8E48913E50953552DAFA6,6A5C65DC9247F762FE17BF8D4906E04FE6B31819
Certyfikat będzie dostępny dla wszystkich aplikacji w tym samym planie usługi App Service co aplikacja, która skonfigurowała to ustawienie. Jeśli potrzebujesz, aby aplikacja była dostępna w innym planie usługi App Service, musisz powtórzyć operację Ustawienia aplikacji w aplikacji w tym planie usługi App Service. Aby sprawdzić, czy certyfikat jest ustawiony, przejdź do konsoli Kudu i wydaj następujące polecenie w konsoli debugowania programu PowerShell:
dir cert:\localmachine\root
Aby przeprowadzić testowanie, możesz utworzyć certyfikat z podpisem własnym i wygenerować plik .cer przy użyciu następującego programu PowerShell:
$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"
$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText
$fileName = "exportedcert.cer"
export-certificate -Cert $certThumbprint -FilePath $fileName -Type CERT