Översikt över TLS-avslutning och TLS från slutpunkt till slutpunkt 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.

TLS-avslutning

Application Gateway stöder TLS-avslutning vid gatewayen, varefter trafiken vanligtvis flödar okrypterad till serverdelsservrarna. 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. Om du tar bort det här arbetet från serverdelsservrarna kan de fokusera på vad de är mest effektiva på och 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.

Viktigt!

Certifikatet på lyssnaren kräver att hela certifikatkedjan laddas upp (rotcertifikatet från certifikatutfärdaren, mellanliggande certifikatet och lövcertifikatet) för att upprätta förtroendekedjan.

Kommentar

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 dock inte site.com, så om användarna kommer åt din webbplats utan att skriva det inledande "www" täcker jokerteckencertifikatet inte det.
• Självsignerade 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 serverdelsservrarna. 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, möjligheten att skriva om eller mata in X-Vidarebefordrade-* huvuden och så vidare.

När den konfigureras med TLS-kommunikationsläget från slutpunkt till slutpunkt avslutar Application Gateway TLS-sessionerna vid gatewayen och dekrypterar användartrafik. Därefter appliceras de konfigurerade reglerna för att välja en lämplig serverdels-serverpoolinstans att dirigera trafiken 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. TLS från slutpunkt till slutpunkt aktiveras genom att protokollinställningen anges i HTTP-inställningen för serverdelen till HTTPS, som sedan tillämpas på en serverdelspool.

I Application Gateway v1 SKU-gatewayer tillämpar TLS-principen endast TLS-versionen på klientdelstrafik och definierade chiffer för både klientdels- och serverdelsmå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 serverdelsservrar som antingen har tillåtna certifikat med Application Gateway eller vars certifikat är signerade av välkända CA-myndigheter och certifikatets CN matchar värdnamnet i HTTP-serverdelsinstä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.

Kommentar

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 serverdelsservrar i Pool1 med TLS från slutpunkt till slutpunkt.

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

Application Gateway kommunicerar endast med de serverdelsservrar som antingen har tillåtna certifikat med Application Gateway eller vars certifikat är signerade av välkända CA-myndigheter och certifikatets CN matchar värdnamnet i HTTP-serverdelsinstä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 slutpunkt till slutpunkt med V1 SKU

För att aktivera TLS från slutpunkt till slutpunkt med serverdelsservrarna och för att Application Gateway ska dirigera begäranden till dem måste hälsoavsökningarna lyckas och returnera felfria svar.

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

Endast anslutningar till kända och tillåtna serverdelar tillåts sedan. De återstående serverdelarna anses vara felaktiga av hälsoavsökningarna. Självsignerade certifikat är enbart för testningsändamål och rekommenderas inte för produktions-arbetsbelastningar. Sådana certifikat måste vara tillåtna med programgatewayen enligt beskrivningen i föregående steg innan de kan användas.

Kommentar

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

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.

Kommentar

För att ett TLS/SSL-certifikat ska vara betrott måste det certifikatet för serverdelsservern 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 rekommenderar vi att serverdelsservercertifikatet innehåller både rot- och mellanliggande certifikatutfärdare.

• Om serverdelsservercertifikatet är självsignerat eller signerat av okända CA/mellanhänder måste ett betrott rotcertifikat laddas upp för att aktivera TLS från slutpunkt till slutpunkt i Application Gateway v2. 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 serverdelspoolen med IP-adresser stöds inte i det här scenariot.

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

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.

Klientdels-TLS-anslutning (klient till programgateway)

Scenario	v1	v2
Om klienten anger SNI-huvudet och alla lyssnare för flera platser ä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

Dricks

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.

Serverdels-TLS-anslutning (programgateway till serverdelsservern)

För avsökningstrafik

Scenario	v1	v2
SNI-huvud (server_name) under TLS-handskakningen som FQDN	Ange som FQDN från serverdelspoolen. Enligt RFC 6066 tillåts inte literala IPv4- och IPv6-adresser i SNI-värdnamnet. Obs! FQDN i serverdelspoolen bör DNS matcha serverdelsserverns IP-adress (offentlig eller privat)	SNI-huvudet (server_name) anges som värdnamn från den anpassade avsökningen som är kopplad till HTTP-inställningarna (om det är konfigurerat), annars från värdnamnet som anges i HTTP-inställningarna, annars från det FQDN som nämns i serverdelspoolen. Prioritetsordningen är http-inställningsserverdelspoolen > för anpassad avsökning>. Obs! Om värdnamnen som konfigurerats i HTTP-inställningar och anpassad avsökning skiljer sig, anges SNI enligt prioriteten som värdnamn från den anpassade avsökningen.
Om serverdelspoolens adress är en IP-adress (v1) eller om det anpassade värdnamnet för avsökningen har konfigurerats som IP-adress (v2)	SNI (server_name) kommer inte att anges. Obs! I det här fallet bör serverdelsservern kunna returnera ett standard-/återställningscertifikat och detta bör vara tillåtet i HTTP-inställningarna under autentiseringscertifikatet. Om inget standard-/återställningscertifikat har konfigurerats på serverdelsservern och SNI förväntas kan servern återställa anslutningen och leda till avsökningsfel	I prioritetsordningen som nämnts tidigare, om de har IP-adress som värdnamn, anges inte SNI enligt RFC 6066. Obs! SNI anges inte heller i v2-avsökningar om ingen anpassad avsökning har konfigurerats och inget värdnamn har angetts för HTTP-inställningar eller serverdelspool

Kommentar

Om en anpassad avsökning inte har konfigurerats skickar Application Gateway en standardavsökning i det här formatet – <protokoll>://127.0.0.1:<port>/. För en HTTPS-standardavsökning skickas den till exempel som https://127.0.0.1:443/. Observera att 127.0.0.1 som nämns här endast används som HTTP-värdhuvud och enligt RFC 6066 används inte som SNI-huvud. Mer information om hälsoavsökningsfel finns i felsökningsguiden för serverdelens hälsotillstånd.

För livetrafik

Scenario	v1	v2
SNI-huvud (server_name) under TLS-handskakningen som FQDN	Ange som FQDN från serverdelspoolen. Enligt RFC 6066 tillåts inte literala IPv4- och IPv6-adresser i SNI-värdnamnet. Obs! FQDN i serverdelspoolen bör DNS matcha serverdelsserverns IP-adress (offentlig eller privat)	SNI-huvudet (server_name) anges som värdnamn från HTTP-inställningarna, annars, om alternativet PickHostnameFromBackendAddress väljs eller om inget värdnamn nämns, anges det som FQDN i serverdelspoolkonfigurationen
Om serverdelspoolens adress är en IP-adress eller värdnamnet inte anges i HTTP-inställningarna	SNI anges inte enligt RFC 6066 om serverdelspoolposten inte är ett FQDN	SNI anges som värdnamn från indata-FQDN från klienten och serverdelscertifikatets CN måste matcha med det här värdnamnet.
Värdnamnet anges inte i HTTP-Inställningar, men ett FQDN anges som mål för en medlem i serverdelspoolen	SNI anges som värdnamn från indata-FQDN från klienten och serverdelscertifikatets CN måste matcha med det här värdnamnet.	SNI anges som värdnamn från indata-FQDN från klienten och serverdelscertifikatets CN måste matcha med det här värdnamnet.

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.