Omówienie zakończenia sesji TLS i kompleksowego szyfrowania TLS za pomocą usługi Application Gateway

Transport Layer Security (TLS), wcześniej znany jako Secure Sockets Layer (SSL), to standardowa technologia zabezpieczeń do ustanawiania szyfrowanego połączenia między serwerem internetowym a przeglądarką. Ten link gwarantuje, że wszystkie dane przekazywane między serwerem internetowym a przeglądarkami pozostaną prywatne i zaszyfrowane. Usługa Application Gateway obsługuje zarówno zakończenie protokołu TLS w bramie, jak i kompleksowe szyfrowanie TLS.

Ważne

Od 31 sierpnia 2025 r. wszyscy klienci i serwery zaplecza współdziałające z usługą Azure Application Gateway muszą korzystać z protokołu Transport Layer Security (TLS) 1.2 lub nowszego, ponieważ obsługa protokołów TLS 1.0 i 1.1 zostanie przerwana.

zakończenie szyfrowania TLS

Usługa Application Gateway obsługuje kończenie żądań TLS w bramie, po czym ruch zwykle przepływa niezaszyfrowany do serwerów zaplecza. Istnieje wiele zalet kończenia żądań protokołu TLS w bramie aplikacji:

• Zwiększona wydajność — największy spadek wydajności podczas odszyfrowywania protokołu TLS następuje w początkowym procesie uzgadniania. Aby zwiększyć wydajność, serwer buforuje identyfikatory sesji TLS i zarządza biletami sesji TLS. W przypadku wykonania tej czynności w bramie aplikacji wszystkie żądania z tego samego klienta mogą używać wartości buforowanych. Jeśli odbywa się to na serwerach zaplecza, za każdym razem, gdy żądania klienta przechodzą do innego serwera, klient musi ponownie uwierzytelnić. Użycie biletów TLS może pomóc rozwiązać ten problem, ale nie są one obsługiwane przez wszystkich klientów i mogą być trudne do skonfigurowania i zarządzania.
• Lepsze wykorzystanie serwerów zaplecza — przetwarzanie protokołu SSL/TLS jest bardzo intensywnie obciążane procesorem CPU i staje się coraz bardziej intensywne w miarę zwiększania rozmiarów kluczy. Usunięcie tej pracy z serwerów zaplecza pozwala im skupić się na tym, w czym są najbardziej wydajne, czyli na dostarczaniu treści.
• Inteligentne trasowanie — poprzez odszyfrowanie ruchu, brama aplikacji ma dostęp do zawartości żądania, takiej jak nagłówki, URI itd., i może używać tych danych do kierowania żądań.
• Zarządzanie certyfikatami — certyfikaty muszą być kupowane i instalowane tylko w bramie aplikacji, a nie na wszystkich serwerach zaplecza. Pozwala to zaoszczędzić czas i pieniądze.

Aby skonfigurować kończenie żądań protokołu TLS, należy dodać certyfikat TLS/SSL do odbiornika. Dzięki temu usługa Application Gateway może odszyfrować ruch przychodzący i szyfrować ruch odpowiedzi do klienta. Certyfikat dostarczony do usługi Application Gateway musi być w formacie Wymiany informacji osobistych (PFX), który zawiera zarówno klucze prywatne, jak i publiczne. Obsługiwane algorytmy PFX są wyświetlane w funkcji PFXImportCertStore.

Ważne

Certyfikat na odbiorniku wymaga przesłania całego łańcucha certyfikatów (głównego certyfikatu urzędu certyfikacji, pośrednich certyfikatów i certyfikatu końcowego) w celu ustanowienia łańcucha zaufania.

Uwaga

Usługa Application Gateway nie zapewnia możliwości tworzenia nowego certyfikatu ani wysyłania żądania certyfikatu do urzędu certyfikacji.

Aby połączenie TLS działało, należy upewnić się, że certyfikat TLS/SSL spełnia następujące warunki:

• Obecna data i godzina znajduje się w przedziale dat "Ważny od" i "Ważny do" w certyfikacie.
• „Nazwa ogólna” (CN) certyfikatu musi być zgodna z nagłówkiem hosta w żądaniu. Jeśli na przykład klient wysyła żądanie do https://www.contoso.com/, to nazwa wspólna (CN) musi być www.contoso.com.

Jeśli występują błędy dotyczące nazwy pospolitej certyfikatu zaplecza (CN), zobacz nasz przewodnik rozwiązywania problemów.

Certyfikaty obsługiwane podczas rozłączania protokołu TLS

Usługa Application Gateway obsługuje następujące typy certyfikatów:

• Certyfikat CA (Urząd Certyfikacji): certyfikat CA jest certyfikatem cyfrowym wystawionym przez Urząd Certyfikacji.
• Certyfikat EV (rozszerzonej weryfikacji): certyfikat EV jest certyfikatem zgodnym z wytycznymi dotyczącymi certyfikatów standardowych w branży. Spowoduje to przekształcenie paska lokalizatora przeglądarki na zielony i opublikowanie nazwy firmy.
• Certyfikat typu wildcard: ten certyfikat obsługuje dowolną liczbę poddomen bazujących na *.site.com, gdzie Twoja poddomena zastąpi *. Nie obsługuje jednak site.com, więc jeśli użytkownicy uzyskują dostęp do Twojej strony internetowej bez wpisywania wiodącego "www", certyfikat wieloznaczny tego nie obejmie.
• Certyfikaty z podpisem własnym: przeglądarki klienckie nie ufają tym certyfikatom i ostrzegają użytkownika, że certyfikat usługi wirtualnej nie jest częścią łańcucha zaufania. Certyfikaty z podpisem własnym są dobre do testowania lub środowisk, w których administratorzy kontrolują klientów i mogą bezpiecznie pomijać alerty zabezpieczeń przeglądarki. Obciążenia produkcyjne nigdy nie powinny używać certyfikatów z podpisem własnym.

Aby uzyskać więcej informacji, zobacz konfigurowanie kończenia żądań protokołu TLS za pomocą bramy aplikacji.

Rozmiar certyfikatu

Sprawdź sekcję Limity usługi Application Gateway, aby poznać obsługiwany maksymalny rozmiar certyfikatu TLS/SSL.

Kompleksowe szyfrowanie TLS

Możesz nie chcieć, aby komunikacja z serwerami zaplecza była nieszyfrowana. Być może masz wymagania dotyczące zabezpieczeń, wymagania dotyczące zgodności lub aplikacja może akceptować tylko bezpieczne połączenie. aplikacja systemu Azure Gateway ma kompleksowe szyfrowanie TLS w celu obsługi tych wymagań.

Kompleksowe szyfrowanie TLS umożliwia szyfrowanie i bezpieczne przesyłanie poufnych danych do zaplecza podczas korzystania z funkcji równoważenia obciążenia warstwy 7 usługi Application Gateway. Te funkcje obejmują powiązanie sesji oparte na plikach cookie, routing oparty na adresach URL, obsługę routingu na podstawie witryn, możliwość ponownego zapisu lub wstrzykiwania nagłówków X-Forwarded-* itd.

Po skonfigurowaniu w trybie kompleksowej komunikacji TLS usługa Application Gateway przerywa sesje protokołu TLS w bramie i odszyfrowuje ruch użytkowników. Następnie stosuje skonfigurowane reguły, aby wybrać odpowiednie wystąpienie puli serwerów zaplecza w celu skierowania do nich ruchu. Następnie usługa Application Gateway inicjuje nowe połączenie TLS z serwerem zaplecza i ponownie szyfruje dane przy użyciu certyfikatu klucza publicznego serwera zaplecza przed przesłaniem żądania do zaplecza. Każda odpowiedź z serwera sieci Web przechodzi przez ten sam proces z powrotem do użytkownika końcowego. Funkcja TLS od końca do końca jest włączona poprzez ustawienie protokołu w Ustawieniach HTTP zaplecza na HTTPS, które jest następnie stosowane do puli backend.

W bramach jednostki SKU usługi Application Gateway w wersji 1, zasady protokołu TLS stosują wersję tylko do ruchu frontonu, a zdefiniowane szyfry zarówno do celów frontonu, jak i zaplecza. W bramach Application Gateway v2 SKU zasady TLS dotyczą tylko ruchu frontend, połączenia TLS zaplecza będą zawsze negocjowane zgodnie z protokołami od wersji TLS 1.0 do TLS 1.2.

Usługa Application Gateway komunikuje się tylko z tymi serwerami zaplecza, które mają certyfikat umieszczony na liście dozwolonych w usłudze Application Gateway, lub których certyfikaty są podpisane przez renomowane urzędy certyfikacji, a CN certyfikatu jest zgodne z nazwą hosta w ustawieniach zaplecza HTTP. Obejmują one zaufane usługi platformy Azure, takie jak Azure App Service/Web Apps i Azure API Management.

Jeśli certyfikaty członków w puli zaplecza technicznego nie są podpisane przez dobrze znane urzędy certyfikacji (CA), każde wystąpienie w puli zaplecza technicznego z włączonym TLS od końca do końca musi być skonfigurowane z certyfikatem, aby zapewnić bezpieczną komunikację. Dodanie certyfikatu zapewnia, że brama aplikacji komunikuje się tylko z zaufanymi instancjami zaplecza. Dodatkowo zabezpiecza to kompleksową komunikację.

Uwaga

Certyfikat dodany do ustawienia HTTP zaplecza w celu uwierzytelniania serwerów zaplecza może być ten sam co certyfikat dodany do nasłuchiwacza w celu zakończenia protokołu TLS w Application Gateway lub inny w celu zwiększenia bezpieczeństwa.

W tym przykładzie żądania używające protokołu TLS1.2 są kierowane do serwerów zaplecza w puli Pool1 przy użyciu kompleksowego protokołu TLS.

Kompleksowe protokoły TLS i zezwalanie na wyświetlanie listy certyfikatów

Usługa Application Gateway komunikuje się tylko z tymi serwerami zaplecza, które mają certyfikat umieszczony na liście dozwolonych w usłudze Application Gateway, lub których certyfikaty są podpisane przez renomowane urzędy certyfikacji, a CN certyfikatu jest zgodne z nazwą hosta w ustawieniach zaplecza HTTP. Istnieją pewne różnice w procesie kompleksowej konfiguracji protokołu TLS w odniesieniu do używanej wersji usługi Application Gateway. W poniższej sekcji opisano wersje osobno.

Kompleksowa obsługa protokołu TLS przy użyciu jednostki SKU w wersji 1

Aby umożliwić kompleksowe połączenie TLS z serwerami zaplecza oraz aby Application Gateway mógł przekazywać im żądania, sondy kontrolne muszą zakończyć się sukcesem i zwrócić prawidłową odpowiedź.

W przypadku sond kondycji HTTPS jednostka Application Gateway v1 SKU używa dokładnego dopasowania certyfikatu uwierzytelniania (klucza publicznego certyfikatu serwera zaplecza, a nie certyfikatu głównego), które jest przekazywane do ustawień HTTP.

Następnie zezwala się tylko na połączenia ze znanymi i dozwolonymi backendami. Pozostałe serwery są uznawane za niezdrowe przez sondy zdrowia. Certyfikaty z podpisem własnym są przeznaczone tylko do celów testowych i nie są zalecane dla obciążeń w środowisku produkcyjnym. Takie certyfikaty muszą być dodane do listy dozwolonych w bramie aplikacji, zgodnie z opisem w poprzednich krokach, zanim będą mogły być używane.

Uwaga

Uwierzytelnianie i konfiguracja zaufanego certyfikatu głównego nie są wymagane dla zaufanych usług Azure, takich jak Azure App Service. Są one domyślnie uznawane za zaufane.

Kompleksowe szyfrowanie typu end-to-end TLS w wersji SKU v2

Certyfikaty uwierzytelniania zostały wycofane i zastąpione przez zaufane certyfikaty główne w jednostce SKU usługi Application Gateway w wersji 2. Działają podobnie do certyfikatów uwierzytelniania z kilkoma kluczowymi różnicami:

• Certyfikaty podpisane przez dobrze znane urzędy certyfikacji, których CN pasuje do nazwy hosta w ustawieniach zaplecza HTTP, nie wymagają żadnych dodatkowych kroków, aby end-to-end TLS działał poprawnie.

  Na przykład, jeśli certyfikaty zaplecza są wystawione przez renomowany urząd certyfikacji i mają wartość CN contoso.com, a pole hosta w ustawieniach HTTP zaplecza również ma wpis contoso.com, nie są potrzebne żadne dodatkowe kroki. Protokół ustawień zaplecza HTTP można ustawić na HTTPS, a zarówno sonda kondycji, jak i ścieżka danych będą obsługiwane przez protokół TLS. Jeśli używasz usługi Azure App Service lub innych usług internetowych platformy Azure jako zaplecza, są one domyślnie zaufane, a żadne dalsze kroki nie są wymagane do TLS od końca do końca.

Uwaga

Aby certyfikat TLS/SSL był zaufany, ten certyfikat serwera zaplecza musi zostać wystawiony przez urząd certyfikacji, który jest dobrze znany. Jeśli certyfikat nie został wystawiony przez zaufany urząd certyfikacji, brama aplikacji sprawdzi, czy certyfikat urzędu wystawiającego certyfikat został wystawiony przez zaufany urząd certyfikacji, i tak dalej, dopóki nie zostanie znaleziony zaufany urząd certyfikacji (po czym zostanie nawiązane zaufane, bezpieczne połączenie) lub nie można odnaleźć zaufanego urzędu certyfikacji (w takim przypadku brama aplikacji uzna zaplecze za niezdatne). W związku z tym zaleca się, aby certyfikat serwera backend zawierał zarówno główne, jak i pośrednie certyfikaty urzędów certyfikacji.

• Jeśli certyfikat serwera zaplecza jest samopodpisany lub podpisany przez nieznany urząd certyfikacji lub pośredników, aby włączyć pełny protokół TLS w usłudze Application Gateway w wersji 2, należy przekazać zaufany certyfikat główny. Usługa Application Gateway będzie komunikować się tylko z zapleczami, których certyfikat główny serwera jest zgodny z jednym z zaufanych certyfikatów głównych w ustawieniu http serwera zaplecza skojarzonym z pulą.

• Oprócz dopasowania certyfikatu głównego, usługa Application Gateway w wersji 2 również sprawdza, czy ustawienie hosta w ustawieniach HTTP zaplecza jest zgodne z nazwą wspólną (CN) podaną przez certyfikat TLS/SSL serwera zaplecza. Podczas próby nawiązania połączenia TLS z zapleczem, Application Gateway w wersji 2 konfiguruje rozszerzenie SNI (Server Name Indication) dla hosta określonego w ustawieniu HTTP zaplecza.

• Jeśli wybierając nazwę hosta z docelowego zaplecza zostanie wybrana zamiast pola Host w ustawieniach http zaplecza, nagłówek SNI jest zawsze ustawiany na FQDN puli zaplecza, a CN na certyfikacie TLS/SSL serwera zaplecza musi odpowiadać jego FQDN. Członkowie puli back-end z adresami IP nie są obsługiwani w tym scenariuszu.

• Certyfikat główny jest certyfikatem głównym zakodowanym w formacie base64 z certyfikatów serwera zaplecza.

Różnice SNI w SKU wersji 1 i 2

Jak wspomniano wcześniej, usługa Application Gateway przerywa ruch TLS z klienta na odbiorniku usługi Application Gateway (nazwijmy go połączeniem frontonu), odszyfrowuje ruch, stosuje reguły niezbędne do określenia serwera zaplecza, do którego ma zostać przekazane żądanie, i ustanawia nową sesję protokołu TLS z serwerem zaplecza (nazwijmy go połączeniem zaplecza).

W poniższych tabelach opisano różnice w SNI między jednostkami SKU w wersjach v1 i v2 pod względem połączeń warstwy frontowej i warstwy zaplecza.

Połączenie TLS frontonu (klient z bramą aplikacji)

Scenariusz	v1	v2
Jeśli klient określa nagłówek SNI, a wszystkie odbiorniki z wieloma lokacjami są włączone z flagą "Wymagaj SNI"	Zwraca odpowiedni certyfikat i jeśli witryna nie istnieje (zgodnie z nazwą_serwera), połączenie zostanie zresetowane.	Zwraca odpowiedni certyfikat, jeśli jest dostępny, w przeciwnym razie zwraca certyfikat pierwszego odbiornika HTTPS zgodnie z kolejnością określoną przez reguły routingu żądań skojarzone z odbiornikami HTTPS
Jeśli klient nie określi nagłówka SNI i wszystkie nagłówki dla wielu witryn mają włączoną opcję "Wymagaj SNI"	Resetuje połączenie	Zwraca certyfikat pierwszego odbiornika HTTPS zgodnie z kolejnością określoną przez reguły routingu żądań skojarzone z odbiornikami HTTPS
Jeśli klient nie określi nagłówka SNI i jeśli istnieje podstawowy odbiornik skonfigurowany przy użyciu certyfikatu	Zwraca certyfikat skonfigurowany w podstawowym odbiorniku do klienta (domyślny lub rezerwowy certyfikat)	Zwraca certyfikat skonfigurowany w odbiorniku podstawowym

Uwaga

Jeśli klient nie określa nagłówka SNI, zaleca się, aby użytkownik dodał podstawowy odbiornik i regułę, aby przedstawić domyślny certyfikat SSL/TLS.

Tip

Flagę SNI można skonfigurować przy użyciu programu PowerShell lub przy użyciu szablonu usługi ARM. Aby uzyskać więcej informacji, zobacz RequireServerNameIndication i Szybkie rozpoczęcie: kieruj ruchem internetowym za pomocą Azure Application Gateway - szablon ARM.

Połączenie TLS backendowe (brama aplikacyjna do serwera zaplecza)

Dla ruchu sondowego

Scenariusz	v1	v2
Po skonfigurowaniu nazwy FQDN lub SNI	Ustaw jako FQDN z puli back-endowej. Zgodnie z RFC 6066 literalne adresy IPv4 i IPv6 nie są dozwolone w nazwie hosta SNI.	Wartość SNI jest ustawiana na podstawie typu weryfikacji protokołu TLS w ustawieniach zaplecza. 1. Pełna walidacja — sondy używają SNI w następującej kolejności pierwszeństwa: a) Niestandardowa nazwa hosta sondy zdrowotnej b) Nazwa hosta ustawienia zaplecza (albo zgodnie z wartością przesłoniętą, albo wybierając z serwera zaplecza) 2. Konfigurowalne Użyj określonego SNI: sondy używają tej stałej nazwy hosta do weryfikacji. Pomiń SNI: brak walidacji nazwy podmiotu.
Jeśli nazwa domenowa FQDN lub SNI nie jest skonfigurowana (dostępny jest tylko adres IP)	SNI (server_name) nie zostanie ustawiona. Uwaga: W takim przypadku serwer zaplecza powinien mieć możliwość zwrócenia certyfikatu domyślnego/rezerwowego. Powinno to być wymienione na liście dozwolonych w ustawieniach protokołu HTTP w ramach certyfikatu uwierzytelniania. Jeśli na serwerze zaplecza nie skonfigurowano certyfikatu domyślnego/rezerwowego i oczekiwane jest SNI, serwer może zresetować połączenie, co doprowadzi do niepowodzeń sondy.	Jeśli ustawienia sondy niestandardowej lub zaplecza używają adresu IP w polu nazwa hosta, SNI nie jest ustawione zgodnie z RFC 6066. Dotyczy to przypadków, w których sonda domyślna używa wartości 127.0.0.1.

Dla bieżącego ruchu drogowego

Scenariusz	v1	v2
Gdy dostępny jest FQDN lub SNI	SNI jest ustawiane przy użyciu FQDN serwera backend.	Wartość SNI jest ustawiana na podstawie typu weryfikacji protokołu TLS w ustawieniach zaplecza. 1. Pełna walidacja — SNI jest ustawiana zgodnie z następującą kolejnością pierwszeństwa: a) Nazwa hosta zaplecza serwerowego (zgodnie z wartością nadpisaną lub wybierz z serwera zaplecza) b) Nagłówek hosta przychodzącego żądania klienta 2. Konfigurowalne Użyj określonego SNI: używa tej ustalonej nazwy hosta do weryfikacji. Pomiń SNI: brak walidacji nazwy podmiotu.
Gdy pełna domena (FQDN) lub SNI nie jest dostępna (dostępny jest tylko adres IP)	SNI nie zostanie ustawiona zgodnie z RFC 6066, jeśli wpis puli zaplecza nie jest w pełni kwalifikowaną nazwą domeny (FQDN).	SNI nie zostanie ustawiona zgodnie z RFC 6066.

Następne kroki

Po zapoznaniu się z end-to-end TLS przejdź do Konfigurowanie end-to-end TLS przy użyciu usługi Application Gateway i programu PowerShell, aby utworzyć bramę aplikacji przy użyciu end-to-end TLS.