Přehled ukončení protokolu TLS a koncového šifrování TLS se službou Application Gateway

Protokol TLS (Transport Layer Security), dříve označovaný jako SSL (Secure Sockets Layer), je standardní technologie zabezpečení pro vytvoření šifrovaného propojení mezi webovým serverem a prohlížečem. Tento odkaz zajišťuje, že všechna data předaná mezi webovým serverem a prohlížeči zůstanou soukromá a šifrovaná. Application Gateway podporuje ukončení protokolu TLS na bráně i koncové šifrování TLS.

Důležité

Od 31. srpna 2025 musí všichni klienti a back-endové servery pracující se službou Aplikace Azure lication Gateway používat protokol TLS (Transport Layer Security) 1.2 nebo vyšší, protože podpora protokolu TLS 1.0 a 1.1 bude ukončena.

ukončení šifrování TLS

Application Gateway podporuje ukončení protokolu TLS na bráně, po kterém provoz obvykle proudí nešifrovaný na back-endové servery. V aplikační bráně existuje řada výhod ukončení protokolu TLS:

• Vylepšený výkon – Největší zatížení výkonu při dešifrování protokolu TLS je počáteční handshake. Aby se zlepšil výkon, server, který provádí dešifrování, ukládá ID relací TLS do paměti cache a spravuje lístky relací TLS. Pokud se to provádí ve službě Application Gateway, můžou všechny požadavky ze stejného klienta používat hodnoty uložené v mezipaměti. Pokud je to hotové na back-end serverech, musí se klient pokaždé, když klientovy požadavky přejdou na jiný server, znovu ověřit. Použití lístků TLS může pomoct tento problém zmírnit, ale nejsou podporovány všemi klienty a můžou být obtížné nakonfigurovat a spravovat.
• Lepší využití back-endových serverů – zpracování SSL/TLS je velmi náročné na procesor a s rostoucí velikostí klíčů se stává náročnějším. Odebráním této práce z back-endových serverů se můžou soustředit na to, co jsou nejúčinnější a co nejefektivněji doručují obsah.
• Inteligentní směrování – Dešifrováním provozu má aplikační brána přístup k obsahu požadavku, jako jsou hlavičky, identifikátor URI atd., a může tato data použít ke směrování požadavků.
• Správa certifikátů – Certifikáty je potřeba zakoupit a nainstalovat jenom na aplikační bránu a ne všechny back-endové servery. To šetří čas i peníze.

Pokud chcete nakonfigurovat ukončení protokolu TLS, musí se do naslouchacího procesu přidat certifikát TLS/SSL. To umožňuje službě Application Gateway dešifrovat příchozí provoz a šifrovat provoz odpovědí klientovi. Certifikát poskytnutý službě Application Gateway musí být ve formátu PFX (Personal Information Exchange), který obsahuje privátní i veřejné klíče. Podporované algoritmy PFX jsou uvedeny ve funkci PFXImportCertStore.

Důležité

Certifikát na nasloucháči vyžaduje, aby byl nahrán celý řetěz certifikátů (kořenový certifikát z certifikační autority, mezilehlé a listový certifikát) pro vytvoření řetězu důvěry.

Poznámka:

Application Gateway neposkytuje žádnou možnost vytvořit nový certifikát ani odeslat žádost o certifikát certifikační autoritě.

Aby připojení TLS fungovalo, musíte zajistit, aby certifikát TLS/SSL splňoval následující podmínky:

• Aktuální datum a čas jsou v rozsahu kalendářních dat "Platné od" a "Platné do" v certifikátu.
• Běžný název certifikátu (CN) odpovídá hlavičce hostitele v požadavku. Například pokud klient posílá požadavek na https://www.contoso.com/, musí být CN www.contoso.com.

Pokud máte chyby s obecným názvem backendového certifikátu (CN), prohlédněte si náš průvodce odstraňováním potíží.

Certifikáty podporované pro ukončení protokolu TLS

Application Gateway podporuje následující typy certifikátů:

• Certifikát certifikační autority (certifikační autorita): Certifikát certifikační autority je digitální certifikát vydaný certifikační autoritou (CA).
• Certifikát EV (Rozšířené ověřování): Certifikát EV je certifikát, který odpovídá standardním pokynům pro oborové certifikáty. Tím se změní panel lokátoru prohlížeče na zelenou a publikuje také název společnosti.
• Zástupný certifikát: Tento certifikát podporuje libovolný počet subdomén pro *.site.com, kde vaše subdoména nahradí *. Nepodporuje ale site.com, takže v případě, že uživatelé přistupují k vašemu webu, aniž by museli zadávat úvodní "www", certifikát se zástupným znakem to nepokryje.
• Certifikáty podepsané svým držitelem: Klientské prohlížeče tyto certifikáty nedůvěřují a upozorní uživatele, že certifikát virtuální služby není součástí řetězu důvěryhodnosti. Certifikáty podepsané svým držitelem jsou vhodné pro testování nebo prostředí, kde správci řídí klienty a můžou bezpečně obejít výstrahy zabezpečení prohlížeče. Produkční úlohy by nikdy neměly používat certifikáty podepsané svým držitelem.

Další informace najdete v tématu Konfigurace ukončení protokolu TLS se službou Application Gateway.

Velikost certifikátu

V části Omezení služby Application Gateway zjistěte, jaká maximální podporovaná velikost certifikátu TLS/SSL je podporovaná.

Kompletní šifrování TLS

Možná nebudete chtít nešifrovanou komunikaci s back-end servery. Možná máte požadavky na zabezpečení, požadavky na dodržování předpisů nebo aplikace může přijímat pouze zabezpečené připojení. Azure Application Gateway má end-to-end šifrování TLS pro podporu těchto požadavků.

Kompletní protokol TLS umožňuje šifrovat a bezpečně přenášet citlivá data do back-endu při používání funkcí vyrovnávání zatížení vrstvy 7 služby Application Gateway. Mezi tyto funkce patří afinitní spřažení relací na základě cookies, směrování podle adresy URL, podpora směrování podle webů, možnost přepisování nebo vkládání hlaviček X-Forwarded-* a další možnosti.

Když je služba Application Gateway nakonfigurovaná s kompletním komunikačním režimem TLS, ukončí relace PROTOKOLU TLS na bráně a dešifruje uživatelský provoz. Následně použije nakonfigurovaná pravidla k výběru příslušné instance back-endového fondu, na kterou provoz přesměruje. Služba Application Gateway pak zahájí nové připojení TLS k back-endovému serveru a před přenosem požadavku do back-endu znovu zašifruje data pomocí certifikátu veřejného klíče back-endového serveru. Každá odpověď webového serveru prochází ke koncovému uživateli stejným procesem. End-to-end TLS je povolen nastavením protokolu v Nastavení HTTP back-endu na HTTPS, který se pak aplikuje na fond back-endu.

V aplikacích typu Application Gateway SKU v1 se zásada protokolu TLS vztahuje na verzi protokolu TLS pouze v rámci provozu na front endu a na definované šifry pro front end i back end. V branách verze Application Gateway v2 se zásady TLS vztahují pouze na front-endový provoz, zatímco připojení back-endu TLS budou vždy vyjednávána pomocí verzí TLS od 1.0 do 1.2.

Application Gateway komunikuje jenom s těmi back-endovými servery, které povolily svůj certifikát u Application Gateway, nebo mají certifikáty podepsané známými certifikačními autoritami a CN certifikátu odpovídá názvu hostitele v nastavení HTTP back-endu. Patří mezi ně důvěryhodné služby Azure, jako je služba Aplikace Azure nebo Služba Web Apps a Azure API Management.

Pokud certifikáty členů v back-endovém fondu nejsou podepsané dobře známými certifikačními autoritami, musí být každá instance v back-endovém fondu s povoleným koncovým protokolem TLS nakonfigurovaná s certifikátem, který umožňuje zabezpečenou komunikaci. Přidáním certifikátu zajistíte, že aplikační brána komunikuje pouze se známými back-endovými instancemi. Tím se dále zabezpečuje kompletní komunikace.

Poznámka:

Certifikát přidaný do Backend nastavení HTTP pro ověření back-endových serverů může být stejný jako certifikát přidaný do naslouchacího pro ukončení protokolu TLS v modulu Application Gateway nebo odlišný pro lepší zabezpečení.

V tomto příkladu se požadavky používající protokol TLS1.2 směrují na back-endové servery ve fondu1 pomocí koncového šifrování TLS.

Koncové šifrování TLS a povolení výpisu certifikátů

Application Gateway komunikuje jenom s těmi back-endovými servery, které povolily svůj certifikát u Application Gateway, nebo mají certifikáty podepsané známými certifikačními autoritami a CN certifikátu odpovídá názvu hostitele v nastavení HTTP back-endu. V procesu kompletního nastavení protokolu TLS s ohledem na používanou verzi služby Application Gateway existují určité rozdíly. Následující část vysvětluje jednotlivé verze.

End-to-end TLS se SKU v1

Pro povolení kompletního zabezpečení TLS s back-endovými servery a pro to, aby služba Application Gateway mohla směrovat požadavky na ně, musí sondy stavu proběhnout úspěšně a vrátit zdravou odpověď.

Pro sondy stavu HTTPS používá SKU služby Application Gateway v1 přesnou shodu s ověřovacím certifikátem (veřejným klíčem certifikátu back-endového serveru, nikoli kořenového certifikátu), které je třeba nahrát do nastavení HTTP.

Pak jsou povolená pouze připojení ke známým a povoleným back-endům. Zbývající servery se považují za nezdravé podle sond zdraví. Certifikáty podepsané svým držitelem slouží pouze k testování a nedoporučují se pro úlohy v produkčním prostředí. Tyto certifikáty musí být zařazené na seznamu povolených pro službu Application Gateway, jak je popsáno v předchozích krocích, před tím, než je lze použít.

Poznámka:

Pro důvěryhodné služby Azure, jako je Aplikace Azure Service, se nevyžaduje ověřování a nastavení důvěryhodného kořenového certifikátu. Jsou standardně považovány za důvěryhodné.

Konec-konec TLS s SKU v2

Ověřovací certifikáty byly ukončeny a nahrazeny důvěryhodnými kořenovými certifikáty ve verzi Application Gateway v2 SKU. Fungují podobně jako ověřovací certifikáty s několika klíčovými rozdíly:

• Certifikáty podepsané dobře známými certifikačními autoritami, jejichž CN odpovídá názvu hostitele v nastavení HTTP backendu, nevyžadují pro správnou funkci TLS žádný další krok.

  Pokud jsou například back-endové certifikáty vystaveny dobře známou certifikační autoritou a má CN contoso.com a pole hostitele nastavení HTTP back-endu je také nastaveno na contoso.com, nejsou potřeba žádné další kroky. Můžete nastavit protokol HTTP back-endu na HTTPS a sonda stavu i cesta k datům by byly s podporou TLS. Pokud jako backend používáte Azure App Service nebo jiné webové služby Azure, jsou implicitně důvěryhodné a pro end-to-end šifrování TLS se nevyžadují žádné další kroky.

Poznámka:

Aby byl certifikát TLS/SSL důvěryhodný, musí certifikát back-endového serveru vydat certifikační autorita, která je dobře známá. Pokud certifikát nevystavil důvěryhodná certifikační autorita, služba Application Gateway pak zkontroluje, jestli certifikát vydávající certifikační autority vydala důvěryhodná certifikační autorita, a tak dále, dokud se nenajde důvěryhodná certifikační autorita (v tomto okamžiku se naváže důvěryhodné zabezpečené připojení), nebo se nenajde žádná důvěryhodná certifikační autorita (v tomto okamžiku služba Application Gateway označí back-end, který není v pořádku). Proto se doporučuje certifikát back-endového serveru obsahovat kořenové i zprostředkující certifikační autority.

• Pokud je certifikát backendového serveru samopodepsaný nebo podepsaný neznámou certifikační autoritou či zprostředkovateli, pak musí být do Application Gateway v2 nahrán důvěryhodný kořenový certifikát, aby bylo možné povolit end-to-end TLS. Application Gateway bude komunikovat pouze s back-endy, jejichž kořenový certifikát serveru odpovídá jednomu ze seznamu důvěryhodných kořenových certifikátů v nastavení HTTP back-endu přidruženém k fondu.

• Kromě shody kořenového certifikátu služba Application Gateway v2 také ověří, jestli nastavení hostitele zadané v nastavení HTTP back-endu odpovídá společnému názvu (CN) certifikátu TLS/SSL back-endového serveru. Při pokusu o navázání připojení TLS k backendu nastaví Application Gateway v2 rozšíření SNI (Server Name Indication) na Host zadaný v nastavení HTTP backendu.

• Pokud je zvoleno „výběr názvu hostitele z backendového cíle“ místo pole Hostitel v nastavení HTTP backendu, pak je záhlaví SNI vždy nastaveno na plně kvalifikovaný název domény backendového fondu a CN (Společný název) na certifikátu TLS/SSL backendového serveru musí odpovídat jeho plně kvalifikovanému názvu domény. V tomto scénáři nejsou podporováni členové poolů back-endu s IP adresami.

• Kořenový certifikát je kořenový certifikát s kódováním base64 z certifikátů back-endového serveru.

Rozdíly SNI v SKU v1 a v2

Jak už jsme zmínili dříve, Služba Application Gateway ukončuje provoz TLS z klienta v naslouchacím procesu služby Application Gateway (pojďme ho volat front-endové připojení), dešifruje provoz, použije potřebná pravidla k určení back-endového serveru, na který se má požadavek přesměrovat, a vytvoří novou relaci TLS s back-endovým serverem (pojďme ho volat back-endové připojení).

Následující tabulky popisují rozdíly v SNI mezi skladovou položku v1 a v2 z hlediska front-endových a back-endových připojení.

Připojení TLS front-endu (klient ke službě Application Gateway)

Scénář	v1	v2
Pokud klient určuje hlavičku SNI a všechny víceuzlové naslouchací procesy jsou povolené příznakem 'Vyžadovat SNI'.	Vrátí příslušný certifikát a pokud lokalita neexistuje (podle server_name), připojení se resetuje.	Vrátí odpovídající certifikát, pokud je k dispozici, v opačném případě vrátí certifikát prvního naslouchacího procesu HTTPS podle pořadí určeného pravidly směrování požadavků přidruženými k naslouchacím procesům HTTPS.
Pokud klient nezadá hlavičku SNI a pokud jsou všechna více-doménová záhlaví povolena s požadavkem "Vyžadovat SNI".	Obnoví připojení.	Vrátí certifikát prvního naslouchacího procesu HTTPS podle pořadí určeného pravidly směrování požadavků přidružených k naslouchacím procesům HTTPS.
Pokud klient nezadá hlavičku SNI a pokud je nakonfigurované základní naslouchací zařízení s certifikátem	Vrátí certifikát nakonfigurovaný v základním naslouchacím procesu klientovi (výchozí nebo záložní certifikát).	Vrátí certifikát nakonfigurovaný v základním naslouchacím procesu.

Poznámka:

Pokud klient nezadá hlavičku SNI, doporučuje se přidání základního poslechového procesu a pravidla pro předložení výchozího certifikátu SSL/TLS.

Tip

Příznak SNI je možné nakonfigurovat pomocí PowerShellu nebo pomocí šablony ARM. Další informace najdete v tématu RequireServerNameIndication a Rychlý přehled: Směrování webového provozu pomocí brány Azure Application Gateway - ARM šablona.

Připojení TLS backend (aplikační brána k backendovému serveru)

Pro provoz sondy

Scénář	v1	v2
Když je nakonfigurovaný plně kvalifikovaný název domény nebo SNI	Nastavte jako plně kvalifikovaný název domény z back-endového fondu. Podle dokumentu RFC 6066 nejsou adresy IPv4 a IPv6 v názvu hostitele SNI povolené.	Hodnota SNI je nastavena na základě typu ověřování TLS v Nastavení back-endu. 1. Úplné ověření – sondy používají SNI v následujícím pořadí priorit: a) Název hostitele vlastní sondy stavu b) Název hostitele pro nastavení backendu (podle přepsané hodnoty nebo výběru z backendového serveru) 2. Konfigurovatelné Použijte konkrétní SNI: Sondy k ověření používají tento pevný název hostitele. Přeskočení SNI: Žádné ověření názvu subjektu
Pokud není nakonfigurovaný plně kvalifikovaný název domény nebo SNI (je k dispozici pouze IP adresa)	SNI (server_name) se nenastaví. Poznámka: V tomto případě by back-endový server měl být schopný vrátit výchozí nebo záložní certifikát a měl by být uvedený v nastavení HTTP v rámci ověřovacího certifikátu. Pokud na back-endovém serveru není nakonfigurovaný žádný výchozí nebo záložní certifikát a očekává se SNI, server může připojení resetovat a dojít k selháním testu	Pokud vlastní sonda nebo nastavení back-endu používá IP adresu v poli pro název hostitele, není SNI nastaveno v souladu s dokumentem RFC 6066. To zahrnuje případy, kdy výchozí sonda používá verzi 127.0.0.1.

Pro živá dopravní data

Scénář	v1	v2
Pokud je k dispozici plně kvalifikovaný název domény nebo SNI	SNI se nastavuje pomocí plně kvalifikovaného názvu domény back-endového serveru.	Hodnota SNI je nastavena na základě typu ověřování TLS v Nastavení back-endu. 1. Úplné ověření – SNI je nastaveno podle následujícího pořadí priorit: a) Název hostitele nastavení backendu (dle přepsané hodnoty nebo výběr z backendového serveru) b) Hostitelská hlavička příchozího požadavku klienta 2. Konfigurovatelné Použijte konkrétní SNI: Pro ověření se používá tento pevný název hostitele. Přeskočení SNI: Žádné ověření názvu subjektu
Pokud plně kvalifikovaný název domény nebo SNI nejsou k dispozici (k dispozici je jenom IP adresa)	SNI se nenastaví podle RFC 6066, pokud položka back-endového fondu není plně kvalifikovaný název domény.	SNI se nenastaví podle dokumentu RFC 6066.

Další kroky

Jakmile se dozvíte o koncovém protokolu TLS, přejděte na Konfigurace koncového šifrování TLS pomocí služby Application Gateway s PowerShellem a vytvořte aplikační bránu pomocí koncového šifrování TLS.