Dela via

TLS från slutpunkt till slutpunkt med Azure Front Door

  • Artikel

Viktigt!

Stödet för TLS 1.0 och 1.1 upphör den 1 mars 2025.

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 klient, till exempel en webbläsare. Den här länken säkerställer att alla data som skickas mellan servern och klienten förblir privata och krypterade.

För att uppfylla dina säkerhets- eller efterlevnadskrav stöder Azure Front Door TLS-kryptering från slutpunkt till slutpunkt. Front Door TLS/SSL-avlastning avslutar TLS-anslutningen, dekrypterar trafiken vid Azure Front Door och krypterar trafiken igen innan den vidarebefordras till ursprunget. När anslutningar till ursprunget använder ursprungets offentliga IP-adress är det en bra säkerhetspraxis att konfigurera HTTPS som vidarebefordringsprotokoll i Azure Front Door. Genom att använda HTTPS som vidarebefordranprotokoll kan du framtvinga TLS-kryptering från slutpunkt till slutpunkt för hela bearbetningen av begäran från klienten till ursprunget. TLS/SSL-avlastning stöds också om du distribuerar ett privat ursprung med Azure Front Door Premium med funktionen Private Link .

Den här artikeln förklarar hur Azure Front Door fungerar med TLS-anslutningar. Mer information om hur du använder TLS-certifikat med egna anpassade domäner finns i HTTPS för anpassade domäner. Information om hur du konfigurerar ett TLS-certifikat på din egen anpassade domän finns i Konfigurera en anpassad domän i Azure Front Door med hjälp av Azure Portal.

TLS-kryptering från slutpunkt till slutpunkt

Med TLS från slutpunkt till slutpunkt kan du skydda känsliga data under överföring till ursprunget samtidigt som du drar nytta av Azure Front Door-funktioner som global belastningsutjämning och cachelagring. Några av funktionerna omfattar även URL-baserad routning, TCP-delning, cachelagring på gränsen som är närmast klienterna och anpassning av HTTP-begäranden vid gränsen.

Azure Front Door avlastar TLS-sessionerna vid gränsen och dekrypterar klientbegäranden. Sedan tillämpas de konfigurerade routningsreglerna för att dirigera begäranden till lämpligt ursprung i ursprungsgruppen. Azure Front Door startar sedan en ny TLS-anslutning till ursprunget och krypterar om alla data med ursprungets certifikat innan begäran skickas till ursprunget. Alla svar från ursprunget krypteras via samma process tillbaka till slutanvändaren. Du kan konfigurera Azure Front Door att använda HTTPS som vidarebefordranprotokoll för att aktivera TLS från slutpunkt till slutpunkt.

TLS-versioner som stöds

Azure Front Door stöder för närvarande fyra versioner av TLS-protokollet: TLS-versionerna 1.0, 1.1, 1.2 och 1.3. Alla Azure Front Door-profiler som skapats efter september 2019 använder TLS 1.2 som standardminimum med TLS 1.3 aktiverat, men TLS 1.0 och TLS 1.1 stöds fortfarande för bakåtkompatibilitet. Stödet för TLS 1.0 och 1.1 upphör den 1 mars 2025.

Även om Azure Front Door stöder TLS 1.2, som introducerade klient-/ömsesidig autentisering i RFC 5246, stöder Azure Front Door för närvarande inte klient-/ömsesidig autentisering (mTLS) ännu.

Du kan konfigurera den lägsta TLS-versionen i Azure Front Door i HTTPS-inställningarna för den anpassade domänen med hjälp av Azure Portal eller Azure REST API. För närvarande kan du välja mellan 1.0 och 1.2. Om du anger TLS 1.2 som lägsta version kan du därför välja den lägsta godtagbara TLS-versionen som Azure Front Door accepterar från en klient. För lägsta TLS-version 1.2 kommer förhandlingen att försöka upprätta TLS 1.3 och sedan TLS 1.2, medan alla fyra versioner för TLS version 1.0 görs för minsta möjliga TLS-version 1.0. När Azure Front Door initierar TLS-trafik till ursprunget försöker den förhandla fram den bästa TLS-versionen som ursprunget kan acceptera på ett tillförlitligt och konsekvent sätt. TLS-versioner som stöds för ursprungsanslutningar är TLS 1.0, TLS 1.1, TLS 1.2 och TLS 1.3. Stödet för TLS 1.0 och 1.1 upphör den 1 mars 2025.

Kommentar

  • Klienter med TLS 1.3 aktiverat krävs för att stödja en av Microsoft SDL-kompatibla EC-kurvor, inklusive Secp384r1, Secp256r1 och Secp521, för att kunna göra begäranden med Azure Front Door med hjälp av TLS 1.3.
  • Vi rekommenderar att klienter använder en av dessa kurvor som sin föredragna kurva under begäranden för att undvika ökad svarstid för TLS-handskakning, vilket kan bero på flera turer för att förhandla om ec-kurvan som stöds.

Certifikat som stöds

När du skapar ditt TLS/SSL-certifikat måste du skapa en fullständig certifikatkedja med en tillåten certifikatutfärdare (CA) som ingår i Microsofts lista över betrodda certifikatutfärdare. Om du använder en icke tillåten certifikatutfärdare kan din begäran avvisas.

Certifikat från interna certifikatutfärdare eller självsignerade certifikat tillåts inte.

OcSP-häftning (Online Certificate Status Protocol)

OCSP-häftning stöds som standard i Azure Front Door och ingen konfiguration krävs.

Origin TLS-anslutning (Azure Front Door till ursprung)

För HTTPS-anslutningar förväntar sig Azure Front Door att ditt ursprung visar ett certifikat från en giltig certifikatutfärdare (CA) med ett ämnesnamn som matchar ursprungsvärdens namn. Om ditt ursprungsvärdnamn till exempel är inställt på myapp-centralus.contosonews.net och certifikatet som ditt ursprung visar under TLS-handskakningen inte har myapp-centralus.contosonews.net eller *.contosonews.net i ämnesnamnet, nekar Azure Front Door anslutningen och klienten ser ett fel.

Kommentar

Certifikatet måste ha en fullständig certifikatkedja med lövcertifikat och mellanliggande certifikat. Rotcertifikatutfärdarcertifikatutfärdarna måste vara en del av Microsofts lista över betrodda certifikatutfärdarcertifikat. Om ett certifikat utan fullständig kedja visas kommer de begäranden som omfattar certifikatet inte att fungera som förväntat.

I vissa användningsfall, till exempel för testning, som en lösning för att lösa misslyckade HTTPS-anslutningar, kan du inaktivera namnkontrollen för certifikatmottagaren för Din Azure Front Door. Observera att ursprunget fortfarande måste presentera ett certifikat med en giltig betrodd kedja, men att det inte behöver matcha ursprungsvärdens namn.

I Azure Front Door Standard och Premium kan du konfigurera ett ursprung för att inaktivera certifikatmottagarens namnkontroll.

I Azure Front Door (klassisk) kan du inaktivera certifikatmottagarens namnkontroll genom att ändra inställningarna för Azure Front Door i Azure Portal. Du kan också konfigurera kontrollen med hjälp av serverdelspoolens inställningar i Azure Front Door-API:erna.

Kommentar

Från säkerhetssynpunkt rekommenderar Microsoft inte att du inaktiverar certifikatmottagarens namnkontroll.

Klientdels-TLS-anslutning (klient till Azure Front Door)

Om du vill aktivera HTTPS-protokollet för säker leverans av innehåll på en anpassad Azure Front Door-domän kan du välja att använda ett certifikat som hanteras av Azure Front Door eller använda ditt eget certifikat.

Mer information finns i HTTPS för anpassade domäner.

Azure Front Door hanterade certifikat tillhandahåller ett TLS/SSL-standardcertifikat via DigiCert och lagras i Key Vault i Azure Front Door.

Om du väljer att använda ett eget certifikat kan du registrera ett certifikat från en certifikatutfärdare som stöds som kan vara en standard-TLS, utökat valideringscertifikat eller till och med ett jokerteckencertifikat. Självsignerade certifikat stöds inte. Lär dig hur du aktiverar HTTPS för en anpassad domän.

Autorotation av certifikat

För det hanterade certifikatalternativet i Azure Front Door hanteras certifikaten och roteras automatiskt inom 90 dagar efter att Azure Front Door har upphört att gälla. För alternativet Azure Front Door Standard/Premium-hanterat certifikat hanteras certifikaten och roteras automatiskt inom 45 dagar efter förfallotiden av Azure Front Door. Om du använder ett Hanterat Azure Front Door-certifikat och ser att certifikatets utgångsdatum är mindre än 60 dagar eller 30 dagar för Standard/Premium SKU kan du skicka in ett supportärende.

För ditt eget anpassade TLS/SSL-certifikat:

  1. Du ställer in den hemliga versionen på "Senaste" för att certifikatet ska roteras automatiskt till den senaste versionen när en nyare version av certifikatet är tillgänglig i ditt nyckelvalv. För anpassade certifikat roteras certifikatet automatiskt inom 3–4 dagar med en nyare version av certifikatet, oavsett vad certifikatets utgångna tid är.

  2. Om en viss version har valts stöds inte autorotation. Du måste välja den nya versionen manuellt för att rotera certifikatet. Det tar upp till 24 timmar innan den nya versionen av certifikatet/hemligheten distribueras.

    Kommentar

    Hanterade Azure Front Door-certifikat (Standard och Premium) roteras automatiskt om domänens CNAME-post pekar direkt till en Front Door-slutpunkt eller indirekt pekar på en Traffic Manager-slutpunkt. Annars måste du verifiera domänägarskapet igen för att rotera certifikaten.

    Du måste se till att tjänstens huvudnamn för Front Door har åtkomst till nyckelvalvet. Se hur du beviljar åtkomst till ditt nyckelvalv. Den uppdaterade distributionsåtgärden för certifikat från Azure Front Door orsakar ingen produktionsavbrott, så länge certifikatets ämnesnamn eller alternativt namn (SAN) för certifikatet inte har ändrats.

Chiffersviter som stöds

För TLS 1.2/1.3 stöds följande chiffersviter:

  • TLS_AES_256_GCM_SHA384 (endast TLS 1.3)
  • TLS_AES_128_GCM_SHA256 (endast TLS 1.3)
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256

Kommentar

För Windows 10- och senare versioner rekommenderar vi att du aktiverar en eller båda ECDHE_GCM chiffersviter för bättre säkerhet. Windows 8.1, 8 och 7 är inte kompatibla med dessa ECDHE_GCM chiffersviter. ECDHE_CBC- och DHE-chiffersviterna har tillhandahållits för kompatibilitet med dessa operativsystem.

När du använder anpassade domäner med TLS 1.0 och 1.1 aktiverade stöds följande chiffersviter:

  • TLS_AES_256_GCM_SHA384 (endast TLS 1.3)
  • TLS_AES_128_GCM_SHA256 (endast TLS 1.3)
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Azure Front Door stöder inte inaktivering eller konfigurering av specifika chiffersviter för din profil.

Nästa steg