Översikt över TLS-avslutning och TLS från ände till ände med Application Gateway

Transport Layer Security (TLS), tidigare känt som Secure Sockets Layer (SSL), är standardsäkerhetstekniken för att upprätta en krypterad länk mellan en webbserver och en webbläsare. Den här länken säkerställer att alla data som skickas mellan webbservern och webbläsare förblir privata och krypterade. Application Gateway stöder både TLS-avslutning på gatewayen samt TLS-kryptering från slutpunkt till slutpunkt.

Important

Från och med den 31 augusti 2025 måste alla klienter och serverdelsservrar som interagerar med Azure Application Gateway använda Transport Layer Security (TLS) 1.2 eller senare, eftersom stödet för TLS 1.0 och 1.1 upphör.

TLS termination

Application Gateway stöder TLS-avslutning vid gatewayen, varefter trafiken vanligtvis flödar okrypterad till backend-servrarna. Det finns ett antal fördelar med att göra TLS-avslutning på programgatewayen:

• Förbättrad prestanda – Den största prestandan när du utför TLS-dekryptering är den första handskakningen. För att förbättra prestandan cachelagrar servern som utför dekrypteringen TLS-sessions-ID:t och hanterar TLS-sessionsbiljetter. Om detta görs på programgatewayen kan alla begäranden från samma klient använda de cachelagrade värdena. Om det görs på serverdelsservrarna måste klienten autentiseras igen varje gång klientens begäranden går till en annan server. Användningen av TLS-biljetter kan hjälpa till att åtgärda det här problemet, men de stöds inte av alla klienter och kan vara svåra att konfigurera och hantera.
• Bättre användning av serverdelsservrarna – SSL/TLS-bearbetningen är mycket processorintensiv och blir allt mer intensiv när nyckelstorlekarna ökar. Genom att ta bort det här arbetet från backend-servrarna kan de fokusera på vad de är mest effektiva på: att leverera innehåll.
• Intelligent routning – Genom att dekryptera trafiken har programgatewayen åtkomst till begärandeinnehållet, till exempel rubriker, URI och så vidare, och kan använda dessa data för att dirigera begäranden.
• Certifikathantering – Certifikat behöver bara köpas och installeras på programgatewayen och inte alla serverdelsservrar. Detta sparar både tid och pengar.

För att konfigurera TLS-avslutning måste ett TLS/SSL-certifikat läggas till i lyssnaren. På så sätt kan Application Gateway dekryptera inkommande trafik och kryptera svarstrafik till klienten. Certifikatet som tillhandahålls till Application Gateway måste vara i PFX-format (Personal Information Exchange), som innehåller både privata och offentliga nycklar. Pfx-algoritmerna som stöds visas i PFXImportCertStore-funktionen.

Important

Certifikatet på lyssnarservern kräver att hela certifikatkedjan laddas upp (rotcertifikatet från certifikatutfärdaren, de mellanliggande certifikaten och lövcertifikatet) för att skapa förtroendekedjan.

Note

Application Gateway ger ingen möjlighet att skapa ett nytt certifikat eller skicka en certifikatbegäran till en certifikatutfärdare.

För att TLS-anslutningen ska fungera måste du se till att TLS/SSL-certifikatet uppfyller följande villkor:

• Att aktuellt datum och tid ligger inom datumintervallet "Giltig från" och "Giltig till" på certifikatet.
• Att certifikatets ”vanliga namn” (CN) matchar värdhuvudet i begäran. Exempelvis om klienten gör en begäran till https://www.contoso.com/, måste CN vara www.contoso.com.

Om du har fel med det vanliga namnet på serverdelscertifikatet (CN) kan du läsa vår felsökningsguide.

Certifikat som stöds för TLS-avslutning

Application Gateway stöder följande typer av certifikat:

• CA-certifikat (certifikatutfärdare): Ett CA-certifikat är ett digitalt certifikat som utfärdats av en certifikatutfärdare (CA)
• EV-certifikat (utökad validering): Ett EV-certifikat är ett certifikat som följer branschstandardriktlinjerna för certifikat. Detta kommer att göra webbläsarlokaliserarfältet grönt och publicera företagsnamnet också.
• Jokerteckencertifikat: Det här certifikatet stöder valfritt antal underdomäner baserat på *.site.com, där underdomänen skulle ersätta *. Det stöder emellertid inte site.com, vilket innebär att om användarna besöker din webbplats utan att skriva det inledande "www", kommer vildkortscertifikatet inte att täcka det.
• Self-Signed certifikat: Klientwebbläsare litar inte på dessa certifikat och varnar användaren om att den virtuella tjänstens certifikat inte ingår i en förtroendekedja. Självsignerade certifikat är bra för testning eller miljöer där administratörer styr klienterna och på ett säkert sätt kan kringgå webbläsarens säkerhetsaviseringar. Produktionsarbetsbelastningar bör aldrig använda självsignerade certifikat.

Mer information finns i konfigurera TLS-avslutning med programgateway.

Certifikatets storlek

Kontrollera avsnittet Gränser för Application Gateway om du vill veta hur stor TLS/SSL-certifikatstorlek som stöds.

TLS-kryptering från slutpunkt till slutpunkt

Du kanske inte vill ha okrypterad kommunikation till bakgrundsservrarna. Du kan ha säkerhetskrav, efterlevnadskrav eller så kan programmet bara acceptera en säker anslutning. Azure Application Gateway har TLS-kryptering från slutpunkt till slutpunkt för att stödja dessa krav.

Med TLS från slutpunkt till slutpunkt kan du kryptera och på ett säkert sätt överföra känsliga data till serverdelen när du använder Application Gateways layer-7-belastningsutjämningsfunktioner. Dessa funktioner omfattar cookiebaserad sessionstillhörighet, URL-baserad routning, stöd för routning baserat på webbplatser, funktionaliteten att skriva om eller mata in X-Forwarded-* headers, etc.

När den konfigureras med TLS-kommunikationsläget från slutpunkt till slutpunkt avslutar Application Gateway TLS-sessionerna vid gatewayen och dekrypterar användartrafik. Sedan tillämpas de konfigurerade reglerna för att välja en lämplig serverdelspoolinstans att dirigera trafik till. Application Gateway initierar sedan en ny TLS-anslutning till serverdelsservern och krypterar om data med serverdelsserverns offentliga nyckelcertifikat innan begäran skickas till serverdelen. Eventuella svar från webbservern genomgår samma process på väg tillbaka till användaren. End-to-end TLS aktiveras genom att protokollinställningen i Backend HTTP-inställning anges till HTTPS, vilket sedan tillämpas på en backendpool.

I Application Gateway v1 SKU gateways, tillämpas TLS-policyn så att TLS-versionen endast gäller för frontendtrafik medan de definierade chifferna tillämpas på både frontend- och backendmål. I Application Gateway v2 SKU-gatewayer gäller TLS-principen endast för klientdelstrafik, serverdels-TLS-anslutningar förhandlas alltid via TLS 1.0 till TLS 1.2-versioner.

Application Gateway kommunicerar endast med de backend-servrar som antingen har vitlistat sina certifikat med Application Gateway eller vars certifikat är signerade av välkända CA-myndigheter och där CN för certifikatet matchar hostnamnet i HTTP-backend-inställningarna. Dessa omfattar betrodda Azure-tjänster som Azure App Service/Web Apps och Azure API Management.

Om certifikaten för medlemmarna i serverdelspoolen inte är signerade av välkända CA-myndigheter måste varje instans i serverdelspoolen med TLS-aktiverad från slutpunkt till slutpunkt konfigureras med ett certifikat för att tillåta säker kommunikation. Genom att lägga till certifikatet ser du till att programgatewayen endast kommunicerar med kända serverdelsinstanser. Detta skyddar kommunikationen från slutpunkt till slutpunkt.

Note

Certifikatet som läggs till i HTTP-inställningen för serverdelen för att autentisera serverdelsservrarna kan vara detsamma som certifikatet som lagts till i lyssnaren för TLS-avslutning vid programgatewayen eller annorlunda för förbättrad säkerhet.

I det här exemplet dirigeras begäranden med TLS1.2 till de bakändeservrar i Pool1 med end-to-end TLS.

TLS från slutpunkt till slutpunkt och tillåt lista över certifikat

Application Gateway kommunicerar endast med de backend-servrar som antingen har vitlistat sina certifikat med Application Gateway eller vars certifikat är signerade av välkända CA-myndigheter och där CN för certifikatet matchar hostnamnet i HTTP-backend-inställningarna. Det finns vissa skillnader i TLS-konfigurationsprocessen från slutpunkt till slutpunkt när det gäller den version av Application Gateway som används. I följande avsnitt beskrivs versionerna individuellt.

TLS från början till slut med v1 SKU

För att aktivera TLS hela vägen med backend-servrarna och för att Application Gateway ska dirigera begäranden till dem måste hälsokontrollerna lyckas och returnera friska svar.

För HTTPS-hälsoavsökningar använder Application Gateway v1 SKU en exakt matchning av autentiseringscertifikatet (offentlig nyckel för baktjänstservercertifikatet snarare än rotcertifikatet) som ska laddas upp till HTTP-inställningarna.

Endast anslutningar till kända och tillåtna serverdelar tillåts sedan. De återstående backend-tjänsterna anses vara ohälsosamma av hälsokontrollerna. Självsignerade certifikat är endast i testsyfte och rekommenderas inte för produktionsarbetsbelastningar. Sådana certifikat måste vara tillåtna med programgatewayen enligt beskrivningen i föregående steg innan de kan användas.

Note

Konfiguration av autentisering och betrott rotcertifikat krävs inte för betrodda Azure-tjänster, till exempel Azure App Service. De anses som standard vara betrodda.

TLS från slutpunkt till slutpunkt med v2 SKU

Autentiseringscertifikat har blivit inaktuella och ersatta av betrodda rotcertifikat i Application Gateway v2 SKU. De fungerar på samma sätt som autentiseringscertifikat med några viktiga skillnader:

• Certifikat som signerats av välkända CA-myndigheter vars CN matchar värdnamnet i HTTP-serverdelsinställningarna kräver inte något ytterligare steg för att TLS från slutpunkt till slutpunkt ska fungera.

  Om serverdelscertifikaten till exempel utfärdas av en välkänd certifikatutfärdare och har ett CN för contoso.com, och serverdels-HTTP-inställningens värdfält också är inställt på contoso.com krävs inga ytterligare steg. Du kan ange http-inställningsprotokollet för serverdelen till HTTPS och både hälsoavsökningen och datasökvägen skulle vara TLS-aktiverad. Om du använder Azure App Service eller andra Azure-webbtjänster som serverdel är dessa också implicit betrodda och inga ytterligare steg krävs för TLS från slutpunkt till slutpunkt.

Note

För att ett TLS/SSL-certifikat ska vara betrott måste certifikatet för backend-servern ha utfärdats av en certifikatutfärdare som är välkänd. Om certifikatet inte har utfärdats av en betrodd certifikatutfärdare kontrollerar programgatewayen sedan om certifikatet för den utfärdande certifikatutfärdare har utfärdats av en betrodd certifikatutfärdare och så vidare tills antingen en betrodd certifikatutfärdare hittas (då upprättas en betrodd, säker anslutning) eller om ingen betrodd CA hittas (då kommer programgatewayen att markera serverdelen som felaktig). Därför rekommenderas att backendservercertifikatet innehåller både rot- och mellanliggande certifikatutfärdare (CA:er).

• Om backend-servercertifikatet i Application Gateway v2 är självsignerat, eller signerat av okända CA/mellanhänder, måste ett betrott rotcertifikat laddas upp för att aktivera änd-till-änd TLS. Application Gateway kommunicerar endast med serverdelar vars servercertifikats rotcertifikat matchar en av listan över betrodda rotcertifikat i den http-inställning för serverdelen som är associerad med poolen.

• Förutom rotcertifikatmatchningen verifierar Application Gateway v2 även om inställningen Värd som anges i http-inställningen för serverdelen matchar inställningen för det gemensamma namnet (CN) som visas av serverdelsserverns TLS/SSL-certifikat. När du försöker upprätta en TLS-anslutning till serverdelen anger Application Gateway v2 SNI-tillägget (Server Name Indication) till den värd som anges i http-inställningen för serverdelen.

• Om du väljer värdnamn från serverdelsmålet i stället för fältet Värd i http-inställningen för serverdelen är SNI-huvudet alltid inställt på serverdelspoolens FQDN och CN på serverdelsserverns TLS/SSL-certifikat måste matcha dess FQDN. Medlemmar i back-end-poolen med IP-adresser stöds inte i det här scenariot.

• Rotcertifikatet är ett base64-kodat rotcertifikat från backend-servercertifikaten.

SNI-skillnader i SKU:n v1 och v2

Som tidigare nämnts avslutar Application Gateway TLS-trafik från klienten i Application Gateway-lyssnaren (vi kallar den klientdelsanslutningen), dekrypterar trafiken, tillämpar de regler som krävs för att fastställa den serverdelsserver som begäran måste vidarebefordras till och upprättar en ny TLS-session med serverdelsservern (vi kallar den serverdelsanslutningen).

I följande tabeller beskrivs skillnaderna i SNI mellan SKU:n v1 och v2 när det gäller klientdels- och serverdelsanslutningar.

Frontend-TLS-anslutning (klient till applikationsgateway)

Scenario	v1	v2
Om klienten specificerar SNI-huvudet och alla lyssnare för flera webbplatser är aktiverade med flaggan "Kräv SNI"	Returnerar lämpligt certifikat och om platsen inte finns (enligt server_name) återställs anslutningen.	Returnerar lämpligt certifikat om det är tillgängligt, annars returneras certifikatet för den första HTTPS-lyssnaren enligt den ordning som anges av de routningsregler för begäran som är associerade med HTTPS-lyssnarna
Om klienten inte anger ett SNI-huvud och om alla sidhuvuden för flera platser är aktiverade med "Kräv SNI"	Återställer anslutningen	Returnerar certifikatet för den första HTTPS-lyssnaren enligt den ordning som anges av de routningsregler för begäran som är associerade med HTTPS-lyssnarna
Om klienten inte anger SNI-huvud och om det finns en grundläggande lyssnare konfigurerad med ett certifikat	Returnerar certifikatet som konfigurerats i den grundläggande lyssnaren till klienten (standardcertifikat eller återställningscertifikat)	Returnerar certifikatet som konfigurerats i den grundläggande lyssnaren

Note

När klienten inte anger ett SNI-huvud rekommenderar vi att användaren lägger till en grundläggande lyssnare och regel för att presentera ett standard-SSL/TLS-certifikat.

Tip

SNI-flaggan kan konfigureras med PowerShell eller med hjälp av en ARM-mall. Mer information finns i RequireServerNameIndication och Snabbstart: Dirigera webbtrafik med Azure Application Gateway – ARM-mall.

Backend-TLS-anslutning (applikationsgateway till backendserver)

För probtrafik

Scenario	v1	v2
När ett FQDN eller SNI har konfigurerats	Ställ in som FQDN från backend-poolen. Enligt RFC 6066 tillåts inte literala IPv4- och IPv6-adresser i SNI-värdnamnet.	SNI-värdet anges baserat på TLS-valideringstypen i serverdelsinställningarna. 1. Fullständig validering – Sonderna använder SNI i följande prioritetsordning: a) Värdnamn för anpassad hälsoavsökning b) Serverdelsinställningens värdnamn (enligt Åsidosätt värde eller Välj från serverdelsservern) 2. Kan konfigureras Använd specifikt SNI: Avsökningarna använder det här fasta värdnamnet för validering. Hoppa över SNI: Ingen validering av ämnesnamn.
När ett FQDN eller SNI INTE har konfigurerats (endast IP-adress är tillgänglig)	SNI (server_name) kommer inte att anges. Not: I det här fallet bör backend-servern kunna returnera ett standard-/reservcertifikat och detta bör vara vitlistat i HTTP-inställningarna under autentiseringscertifikatet. Om inget standard-/reservcertifikat har konfigurerats på serverdelsservern och SNI förväntas kan servern återställa anslutningen, vilket leder till avsökningsfel	Om anpassade avsöknings- eller serverdelsinställningar använder en IP-adress i fältet värdnamn anges inte SNI i enlighet med RFC 6066. Detta inkluderar fall där standardavsökningen använder 127.0.0.1.

För livetrafik

Scenario	v1	v2
När ett FQDN eller SNI är tillgängligt	SNI anges med backend-serverns FQDN.	SNI-värdet anges baserat på TLS-valideringstypen i serverdelsinställningarna. 1. Fullständig validering – SNI anges enligt följande prioritetsordning: a) Serverdelsinställningens värdnamn (enligt åsidosättat värde eller Välj från serverdelsservern) b) Värdrubriken för den inkommande klientbegäran 2. Kan konfigureras Använd specifikt SNI: Använder det här fasta värdnamnet för validering. Hoppa över SNI: Ingen validering av ämnesnamn.
När ett FQDN eller SNI INTE är tillgängligt (endast IP-adress är tillgänglig)	SNI anges inte enligt RFC 6066 om backendpoolposten inte är ett FQDN	SNI anges inte enligt RFC 6066.

Nästa steg

När du har lärt dig mer om TLS från slutpunkt till slutpunkt går du till Konfigurera TLS från slutpunkt till slutpunkt med hjälp av Application Gateway med PowerShell för att skapa en programgateway med hjälp av TLS från slutpunkt till slutpunkt.