Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
SKU Application Gateway v2 wprowadza użycie zaufanych certyfikatów głównych do umożliwienia połączeń TLS z serwerami zaplecza. Ta funkcja usuwa użycie certyfikatów uwierzytelniania (pojedynczych certyfikatów Leaf), które były wymagane w wersji 1 SKU. Certyfikat roota jest zakodowany w formacie Base-64 X.509 (.CER) z serwera certyfikatów zaplecza. Identyfikuje główny urząd certyfikacji, który wystawił certyfikat serwera, a certyfikat serwera jest następnie używany do komunikacji TLS/SSL.
Usługa Application Gateway ufa certyfikatowi witryny internetowej domyślnie, jeśli znany urząd certyfikacji (na przykład GoDaddy lub DigiCert) podpisuje go. Jawne przekazanie certyfikatu root nie jest wymagane w tym przypadku. Aby uzyskać więcej informacji, zobacz Omówienie zakończenia połączenia TLS i kompleksowe szyfrowanie TLS w usłudze Application Gateway. Jeśli jednak masz środowisko deweloperskie/testowe i nie chcesz kupować zweryfikowanego certyfikatu podpisanego przez urząd certyfikacji, możesz utworzyć własny niestandardowy główny urząd certyfikacji i certyfikat liścia podpisany przez ten główny urząd certyfikacji.
Note
Certyfikaty generowane samodzielnie nie są domyślnie zaufane i mogą być trudne do utrzymania. Ponadto mogą używać nieaktualnych zestawów skrótów i szyfrów, które nie są silne. Aby uzyskać lepsze zabezpieczenia, kup certyfikat podpisany przez dobrze znany urząd certyfikacji.
Użyj poniższych opcji, aby wygenerować certyfikat prywatny dla połączeń TLS zaplecza.
Użyj narzędzia generatora certyfikatów prywatnych. Korzystając z podanej nazwy domeny (nazwa pospolita), to narzędzie wykonuje te same kroki, co opisane w tym artykule w celu wygenerowania certyfikatów głównych i serwerów. Za pomocą wygenerowanych plików certyfikatów można natychmiast przekazać certyfikat główny (.CER) do ustawień zaplecza bramy i odpowiedni łańcuch certyfikatów (.PFX) do serwera zaplecza. Hasło do pliku PFX jest również podane w pobranym pliku ZIP.
Użyj poleceń OpenSSL, aby dostosować i wygenerować certyfikaty zgodnie z potrzebami. Postępuj zgodnie z instrukcjami w tym artykule, jeśli chcesz wykonać ten proces samodzielnie.
W tym artykule dowiesz się, jak:
- Stwórz własny dedykowany urząd certyfikacji
- Utwórz certyfikat samopodpisany podpisany przez własny urząd certyfikacji
- Przekazywanie certyfikatu głównego z podpisem własnym do usługi Application Gateway w celu uwierzytelnienia serwera zaplecza
Prerequisites
Program OpenSSL na komputerze z systemem Windows lub Linux
Chociaż inne narzędzia mogą być dostępne do zarządzania certyfikatami, w tym samouczku jest używana biblioteka OpenSSL. Pakiet OpenSSL można znaleźć w wielu dystrybucjach systemu Linux, takich jak Ubuntu.
Serwer internetowy
Na przykład Apache, IIS lub NGINX do testowania certyfikatów.
SKU v2 Application Gateway
Jeśli nie masz istniejącej bramy aplikacji, zobacz Szybki start: bezpośredni ruch internetowy za pomocą usługi Azure Application Gateway — Azure Portal.
Utwórz certyfikat główny urzędu certyfikacji
Utwórz certyfikat głównego urzędu certyfikacji przy użyciu protokołu OpenSSL.
Tworzenie klucza głównego
Zaloguj się na komputerze, na którym jest zainstalowany program OpenSSL, i uruchom następujące polecenie. To polecenie tworzy klucz prywatny root. Klucz nie jest szyfrowany i nie jest chroniony hasłem, więc przechowuj plik contoso.key bezpiecznie.
openssl ecparam -out contoso.key -name prime256v1 -genkey
Utwórz certyfikat główny i podpisz go samodzielnie
Użyj następującego polecenia, aby wygenerować żądanie podpisania certyfikatu (CSR).
openssl req -new -sha256 -key contoso.key -out contoso.csrPo wyświetleniu monitu wprowadź informacje organizacyjne dla niestandardowego urzędu certyfikacji (CA), takie jak kraj/region, stan/prowincja, nazwa organizacji, jednostka organizacyjna (OU) oraz w pełni kwalifikowana nazwa domenowa (ta domena jest wystawcą). Ponieważ klucz główny nie jest chroniony hasłem, OpenSSL nie prosi o podanie hasła.
Użyj następującego polecenia, aby wygenerować certyfikat główny.
openssl x509 -req -sha256 -days 365 -in contoso.csr -signkey contoso.key -out contoso.crtPoprzednie polecenia tworzą certyfikat główny. Ten certyfikat służy do podpisywania certyfikatu serwera.
Tworzenie certyfikatu serwera
Następnie należy utworzyć certyfikat serwera przy użyciu protokołu OpenSSL.
Tworzenie klucza certyfikatu
Użyj następującego polecenia, aby wygenerować klucz certyfikatu serwera.
openssl ecparam -out fabrikam.key -name prime256v1 -genkey
Tworzenie żądania CSR (żądanie podpisania certyfikatu)
Wniosek o certyfikat (CSR) to dokument zawierający klucz publiczny, który przekazuje się urzędowi certyfikacji podczas wnioskowania o certyfikat. Urząd certyfikacji wystawia certyfikat dla tego konkretnego żądania.
Note
Nazwa pospolita certyfikatu serwera musi być inna niż domena wystawcy. Na przykład w tym przypadku cn dla wystawcy jest www.contoso.com i certyfikat serwera CN to www.fabrikam.com.
Użyj następującego polecenia, aby wygenerować csr:
openssl req -new -sha256 -key fabrikam.key -out fabrikam.csrGdy pojawi się pytanie, wpisz informacje organizacyjne dla niestandardowego CA: Kraj/Region, Stan, Organizacja, OU oraz w pełni kwalifikowaną nazwę domeny. Ta domena jest domeną witryny sieci Web i powinna być inna niż wystawca. Podobnie jak klucz root, klucz serwera nie jest chroniony hasłem, więc OpenSSL nie prosi o podanie hasła.
Generowanie certyfikatu przy użyciu certyfikatu CSR i klucza i podpisywanie go przy użyciu klucza głównego urzędu certyfikacji
Użyj następującego polecenia, aby utworzyć certyfikat:
openssl x509 -req -in fabrikam.csr -CA contoso.crt -CAkey contoso.key -CAcreateserial -out fabrikam.crt -days 365 -sha256
Weryfikowanie nowo utworzonego certyfikatu
Użyj następującego polecenia, aby wydrukować dane wyjściowe pliku CRT i zweryfikować jego zawartość:
openssl x509 -in fabrikam.crt -text -noout
Sprawdź pliki w katalogu i upewnij się, że masz następujące pliki:
- contoso.crt
- contoso.key
- fabrikam.crt
- fabrikam.key
Konfigurowanie certyfikatu w ustawieniach protokołu TLS serwera internetowego
Na serwerze internetowym skonfiguruj protokół TLS przy użyciu plików fabrikam.crt i fabrikam.key. Jeśli serwer internetowy nie może pobrać dwóch plików, możesz połączyć je w jeden plik pem lub pfx przy użyciu poleceń OpenSSL.
IIS
Aby uzyskać instrukcje dotyczące importowania certyfikatu i przekazywania ich jako certyfikatu serwera w usługach IIS, zobacz HOW TO: Install Import Imported Certificates on a Web Server in Windows Server 2003 (Jak zainstalować zaimportowane certyfikaty na serwerze sieci Web w systemie Windows Server 2003).
Aby uzyskać instrukcje dotyczące powiązania protokołu TLS, zobacz How to Set Up SSL on IIS 7 (Jak skonfigurować protokół SSL w usługach IIS 7).
Apache
Poniższa konfiguracja to przykładowy host wirtualny skonfigurowany do obsługi protokołu SSL w systemie Apache:
<VirtualHost www.fabrikam:443>
DocumentRoot /var/www/fabrikam
ServerName www.fabrikam.com
SSLEngine on
SSLCertificateFile /home/user/fabrikam.crt
SSLCertificateKeyFile /home/user/fabrikam.key
</VirtualHost>
NGINX
Poniższa konfiguracja to przykładowy blok serwera NGINX z konfiguracją protokołu TLS:
Uzyskiwanie dostępu do serwera przy użyciu certyfikatu z podpisem własnym
Dodaj certyfikat główny do zaufanego głównego magazynu certyfikatów na swojej maszynie. Podczas uzyskiwania dostępu do witryny internetowej upewnij się, że cały łańcuch certyfikatów jest widoczny w przeglądarce.
Note
DNS należy skonfigurować tak, aby
www.fabrikam.comwskazywał nazwę serwera internetowego (w tym przykładzie) na adres IP serwera internetowego. Jeśli nie, możesz edytować plik hostów, aby rozwiązać nazwę.Przejdź do witryny internetowej i kliknij ikonę blokady w polu adresu przeglądarki, aby zweryfikować informacje o witrynie i certyfikacie.
Weryfikowanie konfiguracji za pomocą protokołu OpenSSL
Możesz też użyć protokołu OpenSSL do zweryfikowania certyfikatu.
openssl s_client -connect localhost:443 -servername www.fabrikam.com -showcerts
Prześlij certyfikat główny do ustawień zaplecza usługi Application Gateway
Application Gateway akceptuje zaufany certyfikat główny wyłącznie w postaci certyfikatu X.509 zakodowanego w formacie Base-64, z rozszerzeniem nazwy pliku .cer. X.509 zakodowany w formacie Base64 jest kodowaniem tekstowym i jest to kodowanie, które polecenie openssl x509 wygenerowało już wcześniej w tym artykule dla pliku contoso.crt.
Ponieważ contoso.crt już zawiera klucz publiczny w formacie zakodowanym w Base-64, przemianuj rozszerzenie pliku z .crt na .cer. Ta zmiana nazwy zmienia tylko rozszerzenie pliku. Nie konwertuje kodowania certyfikatu i nie jest tu potrzebna konwersja. Certyfikat, który nie jest jeszcze zakodowany w Base-64, wymaga faktycznej konwersji kodowania zamiast zmiany nazwy.
Azure Portal
Aby załadować zaufany certyfikat główny z portalu, wybierz pozycję Ustawienia zaplecza i wybierz pozycję HTTPS w protokole zaplecza.
Azure PowerShell
Możesz też użyć interfejsu wiersza polecenia platformy Azure lub programu Azure PowerShell, aby przekazać certyfikat główny. Poniższe kroki Azure PowerShell obejmują dodanie zaufanego certyfikatu root do bramki aplikacji, utworzenie sondy zdrowia, utworzenie ustawień backendu, dodanie reguły routingu, a następnie zastosowanie zmian do bramy.
Note
Te kroki zakładają, że brama aplikacyjna appgwv2 w grupie zasobów rgOne, backend pool testbackendpool oraz listener basichttps już istnieją. Wykonaj kroki po kolei w tej samej sesji programu PowerShell, ponieważ każdy krok używa obiektu $gw, który jest pobierany w pierwszym kroku.
Krok 1: Dodaj zaufany certyfikat root
Ten krok zakłada, że brama aplikacyjna appgwv2 istnieje już w grupie zasobów rgOne. Pobiera bramę i zapisuje ją w zmiennej $gw, z której korzysta każdy kolejny krok, oraz przekazuje plik contoso.cer, któremu wcześniej zmieniłeś nazwę.
## Add the trusted root certificate to the Application Gateway
$gw=Get-AzApplicationGateway -Name appgwv2 -ResourceGroupName rgOne
Add-AzApplicationGatewayTrustedRootCertificate `
-ApplicationGateway $gw `
-Name CustomCARoot `
-CertificateFile "C:\Users\surmb\Downloads\contoso.cer"
$trustedroot = Get-AzApplicationGatewayTrustedRootCertificate `
-Name CustomCARoot `
-ApplicationGateway $gw
Krok 2: Stwórz sondę zdrowotną
Ten krok zakłada, że masz $gw zmienną z kroku 1. Tworzy sondę HTTPS dla www.fabrikam.com i przechowuje ją w zmiennej $probe .
Add-AzApplicationGatewayProbeConfig `
-ApplicationGateway $gw `
-Name testprobe `
-Protocol Https `
-HostName "www.fabrikam.com" `
-Path "/" `
-Interval 15 `
-Timeout 20 `
-UnhealthyThreshold 3
$probe = Get-AzApplicationGatewayProbeConfig `
-Name testprobe `
-ApplicationGateway $gw
Krok 3: Stwórz ustawienia backendu
Ten krok zakłada, że masz $gw, $trustedroot, i $probe zmienne z poprzednich kroków. Tworzy ustawienie backendowe, które wykorzystuje zaufany certyfikat root i sondę.
## Add the configuration to the HTTP Setting and don't forget to set the "hostname" field
## to the domain name of the server certificate as this will be set as the SNI header and
## will be used to verify the backend server's certificate. Note that TLS handshake will
## fail otherwise and might lead to backend servers being deemed as Unhealthy by the probes
Add-AzApplicationGatewayBackendHttpSettings `
-ApplicationGateway $gw `
-Name testbackend `
-Port 443 `
-Protocol Https `
-Probe $probe `
-TrustedRootCertificate $trustedroot `
-CookieBasedAffinity Disabled `
-RequestTimeout 20 `
-HostName www.fabrikam.com
$backendhttp = Get-AzApplicationGatewayBackendHttpSettings `
-Name testbackend `
-ApplicationGateway $gw
Krok 4: Stwórz regułę routingu
Ten krok zakłada, że masz zmienną $gw z kroku 1 i zmienną $backendhttp z kroku 3 oraz że odbiornik basichttps i pula zaplecza testbackendpool już istnieją na bramie.
$listener = Get-AzApplicationGatewayHttpListener `
-Name basichttps `
-ApplicationGateway $gw
$bepool = Get-AzApplicationGatewayBackendAddressPool `
-Name testbackendpool `
-ApplicationGateway $gw
Add-AzApplicationGatewayRequestRoutingRule `
-ApplicationGateway $gw `
-Name testrule `
-RuleType Basic `
-BackendHttpSettings $backendhttp `
-HttpListener $listener `
-BackendAddressPool $bepool
Krok 5: Zaktualizuj bramę aplikacyjną
Poprzednie kroki zmieniają tylko obiekt $gw w pamięci. Ten krok zakłada, że masz zmienną $gw z kroku 1, z uwzględnieniem wszystkich wcześniej wprowadzonych zmian, i zapisuje te zmiany w bramie w usłudze Azure.
Set-AzApplicationGateway -ApplicationGateway $gw
Weryfikowanie kondycji komponentów zaplecza bramy aplikacji
- Wybierz widok Backend Health swojej bramy aplikacji, aby sprawdzić, czy sonda jest zdrowa.
- Powinieneś zobaczyć, że status sondy HTTPS jest Zdrowy.
Dalsze kroki
Aby dowiedzieć się więcej na temat protokołu SSL\TLS w usłudze Application Gateway, zobacz Omówienie kończenia żądań protokołu TLS i kompleksowego szyfrowania TLS za pomocą usługi Application Gateway.