A TLS megszüntetésének és végpontok közötti TLS-nek az Application Gateway használatával történő áttekintése

A Transport Layer Security (TLS), korábbi nevén Secure Sockets Layer (SSL) a webkiszolgáló és a böngésző közötti titkosított kapcsolat létrehozására szolgáló szabványos biztonsági technológia. Ez a hivatkozás biztosítja, hogy a webkiszolgáló és a böngészők között átadott összes adat privát és titkosított maradjon. Az Application Gateway támogatja a TLS-lezárásokat az átjárón, valamint a végpontok közötti TLS-titkosítást is.

Fontos

2025. augusztus 31-től az Azure-alkalmazás Gatewayrel kommunikáló összes ügyfélnek és háttérkiszolgálónak a Transport Layer Security (TLS) 1.2-es vagy újabb verzióját kell használnia, mivel a TLS 1.0 és 1.1 támogatása megszűnik.

TLS-visszafejtés

Az Application Gateway támogatja az átjáró TLS-leállítását, amely után a forgalom általában titkosítatlanul áramlik a háttérkiszolgálókra. A TLS-leállítás számos előnnyel jár az Application Gatewayen:

• Jobb teljesítmény – A TLS-visszafejtés során a legnagyobb teljesítménybeli megterhelés a kezdeti kapcsolódási folyamat. A teljesítmény javítása érdekében a visszafejtést végző kiszolgáló gyorsítótárazza a TLS-munkamenet azonosítóit, és kezeli a TLS-munkamenetjegyeket. Ha ez az Application Gatewayen történik, az ugyanazon ügyféltől érkező összes kérés használhatja a gyorsítótárazott értékeket. Ha a háttérkiszolgálókon történik, akkor minden alkalommal, amikor az ügyfél kérései egy másik kiszolgálóra kerülnek, az ügyfélnek újra meg kell adnia a hitelesítést. A TLS-jegyek használata segíthet a probléma megoldásában, de nem minden ügyfél támogatja őket, és nehéz lehet konfigurálni és kezelni őket.
• A háttérkiszolgálók jobb kihasználtsága – az SSL/TLS-feldolgozás nagyon processzorigényes, és a kulcsméretek növekedésével egyre intenzívebbé válik. Ha ezt a feladatot eltávolítják a háttérkiszolgálókról, azok arra összpontosíthatnak, amiben a leghatékonyabbak: a tartalomszolgáltatásra.
• Intelligens útválasztás – A forgalom visszafejtésével az application gateway hozzáfér a kérelem tartalmához, például fejlécekhez, URI-khoz stb., és ezeket az adatokat felhasználhatja a kérések irányításához.
• Tanúsítványkezelés – A tanúsítványokat csak az Application Gatewayen kell megvásárolni és telepíteni, nem pedig az összes háttérkiszolgálón. Ezzel időt és pénzt is megtakaríthat.

A TLS-megszakítás konfigurálásához TLS-/SSL-tanúsítványt kell hozzáadni a figyelőhöz. Ez lehetővé teszi, hogy az Application Gateway visszafejtse a bejövő forgalmat, és titkosítsa az ügyfél válaszforgalmát. Az Application Gatewaynek biztosított tanúsítványnak személyes adatcsere (PFX) formátumban kell lennie, amely tartalmazza a titkos és a nyilvános kulcsokat is. A támogatott PFX-algoritmusok a PFXImportCertStore függvényben találhatók.

Fontos

A figyelő tanúsítványához fel kell tölteni a teljes tanúsítványláncot (a hitelesítésszolgáltató főtanúsítványát, a közbenső tanúsítványokat és az egyedi tanúsítványt) a megbízhatósági lánc létrehozásához.

Feljegyzés

Az Application Gateway nem biztosít semmilyen képességet új tanúsítvány létrehozására vagy tanúsítványkérelem hitelesítésszolgáltatónak való küldésére.

A TLS-kapcsolat működéséhez meg kell győződnie arról, hogy a TLS/SSL-tanúsítvány megfelel a következő feltételeknek:

• Az aktuális dátum és idő a tanúsítvány "Érvényesség kezdete" és "Érvényesség vége" dátumtartományán belül van.
• A tanúsítvány „köznapi neve” (Common Name, CN) megegyezik a kérésben szereplő gazdafejlécével. Ha például az ügyfél a(z) https://www.contoso.com/ címre küldi a kérést, akkor a közös névnek a(z) www.contoso.com címnek kell lennie.

Ha a háttértanúsítvány köznapi nevével (CN) kapcsolatos hibák merülnek fel, tekintse meg a hibaelhárítási útmutatót.

TLS-leállításhoz támogatott tanúsítványok

Az Application Gateway a következő tanúsítványtípusokat támogatja:

• Hitelesítésszolgáltatói tanúsítvány: A hitelesítésszolgáltatói tanúsítvány egy hitelesítésszolgáltató (CA) által kibocsátott digitális tanúsítvány
• EV (kiterjesztett érvényesítési) tanúsítvány: Az EV-tanúsítvány olyan tanúsítvány, amely megfelel az iparági szabványtanúsítványokra vonatkozó irányelveknek. Ezzel zöldre váltja a böngésző keresősávját, és közzéteszi a cég nevét is.
• Helyettesítő tanúsítvány: Ez a tanúsítvány tetszőleges számú altartományt támogat a *.site.com alapján, ahol az altartomány lecseréli a *-t. Ez azonban nem támogatja a site.com, így ha a felhasználók a vezető "www" beírása nélkül férnek hozzá a webhelyhez, a helyettesítő tanúsítvány nem fedi le ezt.
• Önaláírt tanúsítványok: Az ügyfélböngészők nem bíznak ezekben a tanúsítványokban, és figyelmeztetik a felhasználót, hogy a virtuális szolgáltatás tanúsítványa nem része a megbízhatósági láncnak. Az önaláírt tanúsítványok olyan teszteléshez vagy környezetekhez használhatók, ahol a rendszergazdák felügyelik az ügyfeleket, és biztonságosan megkerülhetik a böngésző biztonsági riasztásait. Az éles számítási feladatok soha nem használhatnak önaláírt tanúsítványokat.

További információ: TLS-megszakítás konfigurálása az Application Gateway használatával.

A tanúsítvány mérete

Ellenőrizze az Application Gateway korlátai szakaszt, hogy megtudja, a TLS/SSL-tanúsítvány maximális mérete támogatott.

Végpontok közötti TLS-titkosítás

Előfordulhat, hogy nem szeretne titkosítatlan kommunikációt a háttérkiszolgálókkal. Előfordulhat, hogy biztonsági követelményekkel, megfelelőségi követelményekkel rendelkezik, vagy az alkalmazás csak biztonságos kapcsolatot fogad el. Azure-alkalmazás átjáró végpontok közötti TLS-titkosítással rendelkezik, hogy támogassa ezeket a követelményeket.

A végpontok közötti TLS lehetővé teszi a bizalmas adatok titkosítását és biztonságos továbbítását a háttérrendszerbe az Application Gateway 7. rétegbeli terheléselosztási funkcióinak használata során. Ezek a funkciók közé tartozik a cookie-alapú munkamenet-affinitás, az URL-alapú útválasztás, a webhelyeken alapuló útválasztás támogatása, az X-Forwarded-* fejlécek átírásának vagy beszúrásának lehetősége stb.

Ha teljes körű TLS kommunikációs móddal van konfigurálva, az Application Gateway leállítja a TLS-munkameneteket az átjárón, és visszafejti a felhasználói forgalmat. Ezután alkalmazza a konfigurált szabályokat, hogy kiválassza a megfelelő háttérkészletpéldányt, ahová irányítható a forgalom. Az Application Gateway ezután új TLS-kapcsolatot kezdeményez a háttérkiszolgálóval, és újra titkosítja az adatokat a háttérkiszolgáló nyilvános kulcsú tanúsítványával, mielőtt továbbítanák a kérést a háttérrendszernek. A webkiszolgáló esetleges válasza ugyanilyen módon jut el a végfelhasználóhoz. A végponttól végpontig terjedő TLS engedélyezve van a Háttér HTTP-beállítások protokollparaméterének HTTPS értékre állításával, amelyet a rendszer ezután alkalmaz egy háttérkészletben.

Az Application Gateway v1 SKU átjárókban a TLS-szabályzat csak az előtérbeli forgalomra alkalmazza a TLS-verziót, míg a definiált rejtjelek mind az előtérbeli, mind a háttérbeli célokra vonatkoznak. Az Application Gateway v2 termékváltozatában a TLS-szabályzat csak az előtérbeli forgalomra vonatkozik. A háttérbeli TLS-kapcsolatokat mindig a TLS 1.3 használatával tárgyalja meg, és ha nem érhető el, térjen vissza a TLS 1.2-be.

Az Application Gateway csak azokkal a háttérkiszolgálókkal kommunikál, amelyek tanúsítványukat engedélyeztették az Application Gatewayen, vagy amelyek tanúsítványait jól ismert hitelesítésszolgáltatók írták alá, és a tanúsítvány CN-je megegyezik a háttérkiszolgáló HTTP beállításaiban szereplő gazdagép nevével. Ezek közé tartoznak a megbízható Azure-szolgáltatások, például a Azure-alkalmazás Service/Web Apps és az Azure API Management.

Ha a háttérkészletben lévő tagok tanúsítványait nem ismerik ismert hitelesítésszolgáltatók, akkor a teljes körű TLS-t engedélyező háttérkészlet minden példányát tanúsítványsal kell konfigurálni a biztonságos kommunikáció érdekében. A tanúsítvány hozzáadása biztosítja, hogy az Application Gateway csak ismert háttérpéldányokkal kommunikáljon. Ez tovább védi a végpontok közötti kommunikációt.

Feljegyzés

A háttérbeli HTTP-beállításhoz hozzáadott tanúsítvány, amely a háttérkiszolgálók hitelesítésére szolgál, lehet ugyanaz, mint a figyelőhöz hozzáadott tanúsítvány az alkalmazás-átjáró TLS megszüntetéséhez, vagy különböző is lehet a fokozott biztonság érdekében.

Ebben a példában a TLS1.2-t használó kérések a pool1 háttérkiszolgálóihoz lesznek irányítva végpontok közötti TLS használatával.

Végpontok közötti TLS és tanúsítványok listázásának engedélyezése

Az Application Gateway csak azokkal a háttérkiszolgálókkal kommunikál, amelyek tanúsítványukat engedélyeztették az Application Gatewayen, vagy amelyek tanúsítványait jól ismert hitelesítésszolgáltatók írták alá, és a tanúsítvány CN-je megegyezik a háttérkiszolgáló HTTP beállításaiban szereplő gazdagép nevével. A végpontok közötti TLS beállítási folyamatában van néhány különbség a használt Application Gateway-verzió tekintetében. A következő szakasz egyenként ismerteti a verziókat.

Végpontok közötti TLS a v1 SKU-val

Ha engedélyezni szeretné a végpontok közötti TLS-t a háttérkiszolgálókkal, valamint ahhoz, hogy az Application Gateway átirányítsa a kéréseket hozzájuk, az állapotteszteknek sikeresnek kell lenniük, és kifogástalan választ kell adniuk.

HTTPS-állapottesztek esetén az Application Gateway v1 termékváltozata a http-beállításokba feltöltendő hitelesítési tanúsítvány (a háttérkiszolgáló tanúsítványának nyilvános kulcsa és nem a főtanúsítvány) pontos egyezését használja.

Ezután csak az ismert és engedélyezett háttérrendszerekkel létesített kapcsolatok engedélyezettek. A fennmaradó háttérrendszereket az állapottesztek nem megfelelőnek tekintik. Az önaláírt tanúsítványok csupán tesztelési célokat szolgálnak, és nem ajánlottak éles számítási feladatokra. Az ilyen tanúsítványokat a használatuk előtt engedélyezni kell az Application Gatewayben az előző lépésekben leírtak szerint.

Feljegyzés

A megbízható Azure-szolgáltatásokhoz, például Azure-alkalmazás szolgáltatáshoz nincs szükség hitelesítésre és megbízható főtanúsítvány-beállításra. Alapértelmezés szerint megbízhatónak minősülnek.

Végponti TLS a v2 SKU-val

A hitelesítési tanúsítványok elavultak, és az Application Gateway v2 termékváltozatában megbízható főtanúsítványok váltották fel. A hitelesítési tanúsítványokhoz hasonlóan működnek, néhány fő különbséggel:

• A jól ismert hitelesítésszolgáltatók által aláírt tanúsítványok, amelyek CN-értéke megegyezik a HTTP háttérrendszer beállításaiban szereplő állomásnévvel, nem igényelnek további lépést a végpontok közötti TLS működéséhez.

  Ha például a háttértanúsítványokat egy jól ismert hitelesítésszolgáltató állítja ki, és a közös név contoso.com, és a háttérbeli HTTP-beállítás gazdagépmezője is contoso.com, akkor nincs szükség további lépésekre. Beállíthatja a háttérbeli HTTP beállítások protokollját HTTPS-re, és mind az állapotvizsgálat, mind az adatút TLS-t használna. Ha háttérrendszerként Azure-alkalmazás szolgáltatást vagy más Azure-webszolgáltatásokat használ, akkor ezek is implicit módon megbízhatók, és a teljes körű TLS-hez nincs szükség további lépésekre.

Feljegyzés

Ahhoz, hogy egy TLS/SSL-tanúsítvány megbízható legyen, a háttérkiszolgáló tanúsítványát egy jól ismert hitelesítésszolgáltatónak kell kiállítania. Ha a tanúsítványt nem megbízható hitelesítésszolgáltató adta ki, az Application Gateway ezután ellenőrzi, hogy a kiállító hitelesítésszolgáltató tanúsítványát megbízható hitelesítésszolgáltató adta-e ki, és így tovább, amíg nem talál megbízható hitelesítésszolgáltatót (ekkor megbízható, biztonságos kapcsolat jön létre), vagy nem található megbízható hitelesítésszolgáltató (ekkor az Application Gateway nem jelöli meg a háttérrendszer kifogástalan állapotát). Ezért javasoljuk, hogy a háttérkiszolgáló tanúsítványa tartalmazza a legfelső szintű és a köztes hitelesítésszolgáltatókat is.

• Ha a háttérkiszolgáló tanúsítványa önaláírt vagy ismeretlen hitelesítésszolgáltató/közvetítő által van aláírva, akkor az Application Gateway 2-es verziójában a végpontok közötti TLS engedélyezéséhez megbízható főtanúsítványt kell feltölteni. Az Application Gateway csak olyan háttérrendszerekkel kommunikál, amelyek kiszolgálói tanúsítványának főtanúsítványa megegyezik a készlethez társított háttérrendszerbeli HTTP-beállítás megbízható főtanúsítványainak egyikével.

• A gyökértanúsítvány egyezés mellett az Application Gateway v2 is ellenőrzi, hogy a háttér http beállításban megadott Host beállítás megegyezik-e a háttérkiszolgáló TLS/SSL-tanúsítványa által bemutatott közönséges névvel (CN). Amikor TLS-kapcsolatot próbál létesíteni a háttérrendszerrel, az Application Gateway v2 a kiszolgálónév-jelzés (SNI) kiterjesztést a háttérrendszer HTTP-beállításában megadott gazdagépre állítja.

• Ha a háttérrendszer célállomásából választja ki az állomásnevet a Gazdagép mező helyett a háttérrendszerbeli HTTP-beállításban, akkor az SNI-fejléc mindig a háttértár csomópont teljes tartománynevére van beállítva, és a háttérkiszolgáló TLS/SSL tanúsítványán szereplő CN-nek meg kell egyeznie a teljes tartománynevével (FQDN). Ebben a forgatókönyvben a háttérkészlet ip-címekkel rendelkező tagjai nem támogatottak.

• A főtanúsítvány egy base64 kódolású főtanúsítvány a háttérkiszolgáló tanúsítványaiból.

SNI-különbségek a v1 és a v2 termékváltozatban

Ahogy korábban említettük, az Application Gateway leállítja a TLS-forgalmat az ügyféltől az Application Gateway-figyelőnél (nevezzük előtér-kapcsolatnak), visszafejti a forgalmat, alkalmazza a szükséges szabályokat annak a háttérkiszolgálónak a meghatározásához, amelyre a kérést továbbítani kell, és létrehoz egy új TLS-munkamenetet a háttérkiszolgálóval (nevezzük háttérkapcsolatnak).

Az alábbi táblázatok a V1 és a v2 termékváltozat közötti SNI-különbségeket ismertetik az előtér- és háttérkapcsolatok tekintetében.

Előtérbeli TLS-kapcsolat (ügyfél és Application Gateway)

Forgatókönyv	v1	v2
Ha az ügyfél SNI-fejlécet ad meg, és az összes többhelyes figyelő engedélyezve van az "SNI megkövetelése" jelzővel	Visszaadja a megfelelő tanúsítványt, és ha a hely nem létezik (a server_name szerint), akkor a kapcsolat alaphelyzetbe áll.	Megfelelő tanúsítványt ad vissza, ha elérhető, ellenkező esetben az első HTTPS-figyelő tanúsítványát adja vissza a HTTPS-figyelőkhöz társított kérés-útválasztási szabályok által megadott sorrendnek megfelelően.
Ha az ügyfél nem ad meg SNI-fejlécet, és ha az összes többhelyes fejléc engedélyezve van az "SNI megkövetelése" beállítással	A kapcsolat alaphelyzetbe állítása	Az első HTTPS-figyelő tanúsítványát adja vissza a HTTPS-figyelőkhöz társított kérés-útválasztási szabályok által megadott sorrendnek megfelelően
Ha az ügyfél nem adja meg az SNI-fejlécet, és egy alapszintű figyelő van konfigurálva egy tanúsítvánnyal	Az alapszintű figyelőben konfigurált tanúsítványt adja vissza az ügyfélnek (alapértelmezett vagy tartalék tanúsítvány)	A legmagasabb prioritású útválasztási szabályt tartalmazó HTTPS-figyelő tanúsítványát adja vissza. Az alapszintű figyelőtanúsítvány nem használható tartalékként.

Fontos

A V2 termékváltozat alapértelmezett tanúsítványának viselkedése: Ha egy ügyfél SNI-fejléc nélkül (például IP-cím használatával) csatlakozik, az Application Gateway V2 nem kerül vissza egy alapszintű figyelő tanúsítványába. Ehelyett mindig annak a HTTPS-figyelőnek a tanúsítványát adja vissza, amelynek a társított kérés-útválasztási szabálya a legmagasabb prioritással (legalacsonyabb prioritási számmal) rendelkezik. Ez a viselkedés eltér a V1 SKU-tól, amely a "basic listener" tanúsítványt tartalék megoldásként adja vissza.

Tipp.

Az alapértelmezett tanúsítvány szabályozása SNI-lyukkal: Ha meg szeretné akadályozni, hogy az Application Gateway V2 kitehesse az éles hely tanúsítványát, amikor az ügyfelek SNI nélkül csatlakoznak IP-címmel, konfigurálhat egy "SNI-lyukat":

1. Hozzon létre egy többhelyes HTTPS-figyelőt egy olyan hamis gazdagépnévvel, amely nem felel meg a valós helynek (például sni-hole.invalid).
2. Töltsön fel egy önaláírt tanúsítványt a figyelőbe.
3. Hozzon létre egy kérés-útválasztási szabályt a figyelőhöz, és rendelje hozzá a legmagasabb prioritást (legalacsonyabb prioritási számot) az összes szabályhoz.

Ezzel a konfigurációval a megfelelő SNI-fejléc nélküli kapcsolatok érvényes helytanúsítvány helyett önaláírt tanúsítványt kapnak. Ez megakadályozza, hogy a csak IP-címmel rendelkező kapcsolatok információt szerezzenek be a üzemeltetett webhelyekről.

Háttérszerverhez vezető TLS-kapcsolat (alkalmazás átjáró a háttérszerverhez)

Mintavételi forgalom esetén

Forgatókönyv	v1	v2
Teljes tartománynév vagy SNI konfigurálásakor	Állítsa be teljes tartománynévként a háttérkészletből. Az RFC 6066-nak megfelelően az SNI-gazdagépnév nem engedélyezi a literális IPv4- és IPv6-címeket.	Az SNI-érték a háttérbeállítások TLS-érvényesítési típusa alapján van beállítva. 1. Teljes ellenőrzés – A mintavételek az SNI-t a következő sorrendben használják: a) Az egyéni állapotadat-mintavétel állomásneve b) A háttérrendszer-beállítás hosztneve (a felülírt érték szerint vagy válasszon a háttérszerverből) 2. Konfigurálható Adott SNI használata: A vizsgálatok ezt a rögzített hostnevet használják az érvényesítéshez. SNI kihagyása: Nincs tárgynév-ellenőrzés.
Ha nincs konfigurálva teljes tartománynév vagy SNI (csak IP-cím érhető el)	Az SNI (server_name) nem lesz beállítva. Megjegyzés: Ebben az esetben a háttérkiszolgálónak képesnek kell lennie egy alapértelmezett/tartalék tanúsítvány visszaadására, és ezt engedélyeznie kell a hitelesítési tanúsítvány HTTP-beállításai között. Ha nincs alapértelmezett/tartalék tanúsítvány konfigurálva a háttérkiszolgálón, és SNI az elvárás, a kiszolgáló alaphelyzetbe állíthatja a kapcsolatot, ami teszthibákhoz vezethet	Ha a Custom Probe vagy a Backend beállítások IP-címet használnak a gazdagépnév mezőben, az SNI nincs beállítva az RFC 6066 megfelelően. Ide tartoznak azok az esetek, amikor az alapértelmezett mintavétel a 127.0.0.1-et használja.

Élő forgalom esetén

Forgatókönyv	v1	v2
Ha teljes tartománynév vagy SNI érhető el	Az SNI a háttérkiszolgáló teljes tartománynevével van beállítva.	Az SNI-érték a háttérbeállítások TLS-érvényesítési típusa alapján van beállítva. 1. Teljes ellenőrzés – Az SNI a következő sorrend szerint van beállítva: a) A háttérrendszer beállításainak állomásneve (felülírt érték szerint, vagy válasszon a háttérrendszer kiszolgálóról) b) A bejövő ügyfélkérés Host fejléce 2. Konfigurálható Adott SNI használata: Ezt a rögzített gazdagépnevet használja az ellenőrzéshez. SNI kihagyása: Nincs tárgynév-ellenőrzés.
Ha nem érhető el teljes tartománynév vagy SNI (csak IP-cím érhető el)	Az SNI nem lesz RFC 6066-ra állítva, ha a háttérkészlet-bejegyzés nem teljes tartománynév	Az SNI nem lesz az RFC 6066-nak megfelelően beállítva.

Következő lépések

Miután megismerte a végpontok közötti TLS-t, lépjen a Végpontok közötti TLS konfigurálása az Application Gateway és PowerShell használatával oldalra egy alkalmazást átjáró létrehozásához végpontok közötti TLS használatával.