Overzicht van TLS-beëindiging en end-to-end TLS met Application Gateway

  • Artikel

Transport Layer Security (TLS), voorheen bekend als Secure Sockets Layer (SSL), is de standaardbeveiligingstechnologie voor het tot stand brengen van een versleutelde koppeling tussen een webserver en een browser. Deze koppeling zorgt ervoor dat alle gegevens die tussen de webserver en browsers worden doorgegeven privé en versleuteld blijven. Application Gateway ondersteunt zowel TLS-beëindiging op de gateway als end-to-end TLS-versleuteling.

TLS-beëindiging

Application Gateway ondersteunt TLS-beëindiging op de gateway, waarna verkeer meestal niet-versleuteld naar de back-endservers stroomt. Het uitvoeren van TLS-beëindiging op de toepassingsgateway heeft een aantal voordelen:

  • Verbeterde prestaties : de eerste handshake is de grootste prestatietreffer bij het uitvoeren van TLS-ontsleuteling. Om de prestaties te verbeteren, slaat de server die de ontsleuteling uitvoert TLS-sessie-id's in de cache op en beheert deze TLS-sessietickets. Als dit wordt gedaan op de toepassingsgateway, kunnen alle aanvragen van dezelfde client de waarden in de cache gebruiken. Als dit wordt gedaan op de back-endservers, moet de client elke keer dat de aanvragen van de client naar een andere server gaan, opnieuw worden geverifieerd. Het gebruik van TLS-tickets kan helpen dit probleem te verhelpen, maar ze worden niet door alle clients ondersteund en kunnen moeilijk te configureren en te beheren zijn.
  • Beter gebruik van de back-endservers : SSL/TLS-verwerking is zeer CPU-intensief en wordt steeds intensiever naarmate de sleutelgrootten toenemen. Als u dit werk verwijdert van de back-endservers, kunnen ze zich richten op waar ze het efficiëntst in zijn: het leveren van inhoud.
  • Intelligente routering : door het verkeer te ontsleutelen, heeft de toepassingsgateway toegang tot de aanvraaginhoud, zoals headers, URI, enzovoort, en kan deze gegevens worden gebruikt om aanvragen te routeren.
  • Certificaatbeheer : certificaten hoeven alleen te worden aangeschaft en geïnstalleerd op de toepassingsgateway en niet op alle back-endservers. Dit bespaart zowel tijd als geld.

Als u TLS-beëindiging wilt configureren, moet een TLS/SSL-certificaat worden toegevoegd aan de listener. Hierdoor kan de Application Gateway binnenkomend verkeer ontsleutelen en antwoordverkeer naar de client versleutelen. Het certificaat dat aan de Application Gateway is opgegeven, moet de PFX-indeling (Personal Information Exchange) hebben, die zowel de persoonlijke als de openbare sleutel bevat. De ondersteunde PFX-algoritmen worden vermeld in de functie PFXImportCertStore.

Belangrijk

Voor het certificaat op de listener moet de hele certificaatketen worden geüpload (het basiscertificaat van de CA, de tussenliggende certificaten en het leaf-certificaat) om de vertrouwensketen tot stand te brengen.

Notitie

Application Gateway biedt geen mogelijkheid om een nieuw certificaat te maken of een certificaataanvraag naar een certificeringsinstantie te verzenden.

De TLS-verbinding werkt alleen als u ervoor zorgt dat het TLS/SSL-certificaat aan de volgende voorwaarden voldoet:

  • Dat de huidige datum en tijd binnen het datumbereik 'Geldig vanaf' en 'Geldig tot' op het certificaat vallen.
  • De algemene naam (CN) van het certificaat komt overeen met de host-header in de aanvraag. Als de client bijvoorbeeld een aanvraag indient bij https://www.contoso.com/, moet de algemene naam www.contoso.com zijn.

Als u fouten hebt met de algemene naam (CN) van het back-endcertificaat, raadpleegt u onze gids voor probleemoplossing.

Certificaten die worden ondersteund voor TLS-beëindiging

Application Gateway ondersteunt de volgende typen certificaten:

  • CA-certificaat (certificeringsinstantie): een CA-certificaat is een digitaal certificaat dat is uitgegeven door een certificeringsinstantie (CA)
  • EV-certificaat (uitgebreide validatie): een EV-certificaat is een certificaat dat voldoet aan de industriestandaardrichtlijnen voor certificaten. Hiermee wordt de browserzoekerbalk groen en wordt ook de bedrijfsnaam gepubliceerd.
  • Jokertekencertificaat: dit certificaat ondersteunt een willekeurig aantal subdomeinen op basis van *.site.com, waarbij uw subdomein de *zou vervangen. Het biedt echter geen ondersteuning voor site.com, dus als de gebruikers uw website openen zonder het toonaangevende 'www' te typen, wordt dit niet gedekt door het jokertekencertificaat.
  • Self-Signed certificaten: clientbrowsers vertrouwen deze certificaten niet en waarschuwen de gebruiker dat het certificaat van de virtuele service geen deel uitmaakt van een vertrouwensketen. Zelfondertekende certificaten zijn geschikt voor test- of omgevingen waarin beheerders de clients beheren en de beveiligingswaarschuwingen van de browser veilig kunnen omzeilen. Productieworkloads mogen nooit zelfondertekende certificaten gebruiken.

Zie TLS-beëindiging configureren met application gateway voor meer informatie.

Grootte van het certificaat

Raadpleeg de sectie Application Gateway limieten om te weten welke maximale TLS/SSL-certificaatgrootte wordt ondersteund.

End-to-end TLS-versleuteling

Mogelijk wilt u geen niet-versleutelde communicatie met de back-endservers. Mogelijk hebt u beveiligingsvereisten, nalevingsvereisten of accepteert de toepassing alleen een beveiligde verbinding. Azure Application Gateway beschikt over end-to-end TLS-versleuteling ter ondersteuning van deze vereisten.

Met end-to-end-TLS kunt u gevoelige gegevens versleutelen en veilig verzenden naar de back-end terwijl u de layer-7-taakverdelingsfuncties van Application Gateway gebruikt. Deze functies omvatten sessieaffiniteit op basis van cookies, routering op basis van URL, ondersteuning voor routering op basis van sites, de mogelijkheid om X-Forwarded-*-headers te herschrijven of in te voeren, enzovoort.

Wanneer deze is geconfigureerd met end-to-end TLS-communicatiemodus, beëindigt Application Gateway de TLS-sessies op de gateway en ontsleutelt het gebruikersverkeer. Vervolgens worden de geconfigureerde regels toegepast voor het selecteren van het juiste exemplaar van de back-endgroep waarnaar het verkeer moet worden doorgeleid. Application Gateway start vervolgens een nieuwe TLS-verbinding met de back-endserver en versleutelt gegevens opnieuw met behulp van het openbare sleutelcertificaat van de back-endserver voordat de aanvraag naar de back-endserver wordt verzonden. Reacties van de webserver ondergaan hetzelfde proces terug naar de eindgebruiker. End-to-end-TLS wordt ingeschakeld door de protocolinstelling in HTTP-instelling voor back-end in te stellen op HTTPS, die vervolgens wordt toegepast op een back-endpool.

In Application Gateway v1 SKU-gateways past TLS-beleid de TLS-versie alleen toe op front-endverkeer en de gedefinieerde coderingen op zowel front-end- als back-enddoelen. In Application Gateway v2 SKU-gateways is TLS-beleid alleen van toepassing op front-endverkeer. Back-end-TLS-verbindingen worden altijd onderhandeld via TLS 1.0- naar TLS 1.2-versies.

Application Gateway communiceert alleen met de back-endservers waarvoor het certificaat is toegestaan bij de Application Gateway of waarvan de certificaten zijn ondertekend door bekende CA-instanties en de CN van het certificaat overeenkomt met de hostnaam in de back-endinstellingen van HTTP. Deze omvatten de vertrouwde Azure-services, zoals Azure App Service/Web Apps en Azure API Management.

Als de certificaten van de leden in de back-endpool niet zijn ondertekend door bekende CA-instanties, moet elk exemplaar in de back-endpool waarvoor end-to-end TLS is ingeschakeld, worden geconfigureerd met een certificaat om beveiligde communicatie toe te staan. Als u het certificaat toevoegt, zorgt u ervoor dat de toepassingsgateway alleen communiceert met bekende back-endexemplaren. Hierdoor wordt de end-to-end communicatie verder beveiligd.

Notitie

Het certificaat dat is toegevoegd aan de HTTP-instelling voor de back-end om de back-endservers te verifiëren, kan hetzelfde zijn als het certificaat dat is toegevoegd aan de listener voor TLS-beëindiging bij de toepassingsgateway of anders voor verbeterde beveiliging.

end-to-end TLS-scenario

In dit voorbeeld worden aanvragen met tls1.2 gerouteerd naar back-endservers in Pool1 met behulp van end-to-end TLS.

End-to-end-TLS en vermelding van certificaten toestaan

Application Gateway communiceert alleen met de back-endservers waarvoor het certificaat is toegestaan bij de Application Gateway of waarvan de certificaten zijn ondertekend door bekende CA-instanties en de CN van het certificaat overeenkomt met de hostnaam in de back-endinstellingen van HTTP. Er zijn enkele verschillen in het end-to-end TLS-installatieproces met betrekking tot de versie van Application Gateway gebruikt. In de volgende sectie worden ze afzonderlijk uitgelegd.

End-to-end TLS met de v1-SKU

Als u end-to-end TLS met de back-endservers wilt inschakelen en Application Gateway aanvragen naar deze servers wilt routeren, moeten de statustests slagen en een gezond antwoord retourneren.

Voor HTTPS-statustests gebruikt de Application Gateway v1-SKU een exacte overeenkomst van het verificatiecertificaat (openbare sleutel van het back-endservercertificaat en niet het basiscertificaat) dat moet worden geüpload naar de HTTP-instellingen.

Alleen verbindingen met bekende en toegestane back-ends zijn dan toegestaan. De resterende back-ends worden als beschadigd beschouwd door de statustests. Zelfondertekende certificaten zijn uitsluitend bedoeld voor testdoeleinden en het wordt afgeraden om deze in een productieomgeving te gebruiken. Dergelijke certificaten moeten worden vermeld op de acceptatielijst van de toepassingsgateway, zoals beschreven in de voorgaande stappen voordat ze kunnen worden gebruikt.

Notitie

Verificatie en het instellen van een vertrouwd basiscertificaat zijn niet vereist voor vertrouwde Azure-services zoals Azure App Service. Ze worden standaard beschouwd als vertrouwd.

End-to-end TLS met de v2-SKU

Verificatiecertificaten zijn afgeschaft en vervangen door vertrouwde basiscertificaten in de Application Gateway v2-SKU. Ze werken op dezelfde manier als verificatiecertificaten, met enkele belangrijke verschillen:

  • Certificaten die zijn ondertekend door bekende CA-instanties waarvan de CN overeenkomt met de hostnaam in de HTTP-back-endinstellingen, vereisen geen extra stap om end-to-end TLS te laten werken.

    Als de back-endcertificaten bijvoorbeeld worden uitgegeven door een bekende CA en een CN van contoso.com hebben en het hostveld van de http-instelling van de back-end ook is ingesteld op contoso.com, zijn er geen extra stappen vereist. U kunt het http-instellingsprotocol voor de back-end instellen op HTTPS. Tls is dan ingeschakeld voor zowel de statustest als het gegevenspad. Als u Azure App Service of andere Azure-webservices als back-end gebruikt, worden deze ook impliciet vertrouwd en zijn er geen verdere stappen vereist voor end-to-end-TLS.

Notitie

Als u een TLS/SSL-certificaat wilt vertrouwen, moet dat certificaat van de back-endserver zijn uitgegeven door een bekende CA. Als het certificaat niet is uitgegeven door een vertrouwde CA, controleert de toepassingsgateway of het certificaat van de verlenende CA is uitgegeven door een vertrouwde CA, enzovoort, totdat een vertrouwde CA wordt gevonden (op welk moment een vertrouwde, beveiligde verbinding tot stand wordt gebracht) of er geen vertrouwde CA kan worden gevonden (waarna de toepassingsgateway de back-end als beschadigd markeert). Daarom wordt aanbevolen dat het back-endservercertificaat zowel de basis- als de tussenliggende CA's bevat.

  • Als het back-endservercertificaat zelfondertekend is of is ondertekend door onbekende CA/tussenpersonen, moet een vertrouwd basiscertificaat worden geüpload om end-to-end-TLS in te schakelen in Application Gateway v2. Application Gateway communiceert alleen met back-enden waarvan het basiscertificaat van het servercertificaat overeenkomt met een van de lijst met vertrouwde basiscertificaten in de http-instelling van de back-end die is gekoppeld aan de groep.

  • Naast de basiscertificaatovereenkomst valideert Application Gateway v2 ook of de hostinstelling die is opgegeven in de HTTP-instelling van de back-end overeenkomt met die van de algemene naam (CN) die wordt weergegeven door het TLS/SSL-certificaat van de back-endserver. Wanneer u probeert een TLS-verbinding met de back-end tot stand te brengen, stelt Application Gateway v2 de SNI-extensie (Server Name Indication) in op de host die is opgegeven in de http-instelling van de back-end.

  • Als u hostnaam kiest uit het back-enddoel in plaats van het veld Host in de http-instelling van de back-end, wordt de SNI-header altijd ingesteld op de FQDN van de back-endpool en moet het CN op de back-endserver TLS/SSL-certificaat overeenkomen met de FQDN. Leden van back-endpools met IP-adressen worden niet ondersteund in dit scenario.

  • Het basiscertificaat is een base64-gecodeerd basiscertificaat van de back-endservercertificaten.

SNI-verschillen in de v1- en v2-SKU

Zoals eerder vermeld, beëindigt Application Gateway TLS-verkeer van de client op de Application Gateway listener (laten we dit de front-endverbinding noemen), ontsleutelt het verkeer, past de benodigde regels toe om de back-endserver te bepalen waarnaar de aanvraag moet worden doorgestuurd en brengt een nieuwe TLS-sessie tot stand met de back-endserver (laten we dit de back-endverbinding noemen).

In de volgende tabellen worden de verschillen in SNI tussen de v1- en v2-SKU in termen van front-end- en back-endverbindingen beschreven.

Front-end TLS-verbinding (client naar toepassingsgateway)

Scenario v1 v2
Als de client SNI-header opgeeft en alle listeners voor meerdere sites zijn ingeschakeld met de vlag 'SNI vereisen' Retourneert het juiste certificaat en als de site niet bestaat (volgens de server_name), wordt de verbinding opnieuw ingesteld. Retourneert het juiste certificaat, indien beschikbaar, anders retourneert het certificaat van de eerste HTTPS-listener volgens de volgorde die is opgegeven door de regels voor aanvraagroutering die zijn gekoppeld aan de HTTPS-listeners
Als de client geen SNI-header opgeeft en als alle headers voor meerdere sites zijn ingeschakeld met 'SNI vereisen' De verbinding opnieuw instellen Retourneert het certificaat van de eerste HTTPS-listener volgens de volgorde die is opgegeven door de aanvraagrouteringsregels die zijn gekoppeld aan de HTTPS-listeners
Als de client geen SNI-header opgeeft en er een basislistener is geconfigureerd met een certificaat Retourneert het certificaat dat is geconfigureerd in de basislistener voor de client (standaard- of terugvalcertificaat) Retourneert het certificaat dat is geconfigureerd in de basislistener

Back-end-TLS-verbinding (toepassingsgateway met de back-endserver)

Voor testverkeer

Scenario v1 v2
SNI-header (server_name) tijdens de TLS-handshake als FQDN Stel in als FQDN van de back-endpool. Volgens RFC 6066 zijn letterlijke IPv4- en IPv6-adressen niet toegestaan in SNI-hostnaam.
Opmerking: FQDN in de back-endpool moet DNS worden omgezet in het IP-adres van de back-endserver (openbaar of privé)		 SNI-header (server_name) wordt ingesteld als de hostnaam van de aangepaste test die is gekoppeld aan de HTTP-instellingen (indien geconfigureerd), anders van de hostnaam die wordt vermeld in de HTTP-instellingen, anders van de FQDN die wordt vermeld in de back-endpool. De volgorde van prioriteit is de back-endpool van aangepaste test-HTTP-instellingen >> .
Opmerking: Als de hostnamen die zijn geconfigureerd in HTTP-instellingen en aangepaste tests verschillen, wordt SNI volgens de prioriteit ingesteld als de hostnaam van de aangepaste test.
Als het adres van de back-endpool een IP-adres is (v1) of als de aangepaste testhostnaam is geconfigureerd als IP-adres (v2) SNI (server_name) wordt niet ingesteld.
Opmerking: In dit geval moet de back-endserver een standaard-/terugvalcertificaat kunnen retourneren. Dit moet worden vermeld in de HTTP-instellingen onder verificatiecertificaat. Als er geen standaard-/terugvalcertificaat is geconfigureerd op de back-endserver en SNI wordt verwacht, kan de server de verbinding opnieuw instellen en leiden tot testfouten		 In de volgorde van prioriteit die eerder is vermeld, als ze ip-adres als hostnaam hebben, wordt SNI niet ingesteld volgens RFC 6066.
Opmerking: SNI wordt ook niet ingesteld in v2-tests als er geen aangepaste test is geconfigureerd en er geen hostnaam is ingesteld op HTTP-instellingen of back-endpool

Notitie

Als er geen aangepaste test is geconfigureerd, verzendt Application Gateway een standaardtest in deze indeling: <protocol>://127.0.0.1:<port>/. Voor een standaard-HTTPS-test wordt deze bijvoorbeeld verzonden als https://127.0.0.1:443/. Houd er rekening mee dat de 127.0.0.1 die hier wordt vermeld, alleen wordt gebruikt als HTTP-hostheader en volgens RFC 6066 niet wordt gebruikt als SNI-header. Raadpleeg de handleiding voor het oplossen van problemen met de back-endstatus voor meer informatie over statustestfouten.

Voor liveverkeer

Scenario v1 v2
SNI-header (server_name) tijdens de TLS-handshake als FQDN Stel in als FQDN van de back-endpool. Volgens RFC 6066 zijn letterlijke IPv4- en IPv6-adressen niet toegestaan in SNI-hostnaam.
Opmerking: FQDN in de back-endpool moet DNS worden omgezet in het IP-adres van de back-endserver (openbaar of privé)		 SNI-header (server_name) is ingesteld als de hostnaam uit de HTTP-instellingen. Als anders de optie PickHostnameFromBackendAddress wordt gekozen of als er geen hostnaam wordt vermeld, wordt deze ingesteld als de FQDN in de configuratie van de back-endpool
Als het adres van de back-endpool een IP-adres is of als de hostnaam niet is ingesteld in de HTTP-instellingen SNI wordt niet ingesteld volgens RFC 6066 als de vermelding van de back-endpool geen FQDN is SNI wordt ingesteld als de hostnaam van de invoer-FQDN van de client en de CN van het back-endcertificaat moet overeenkomen met deze hostnaam.
Hostnaam is niet opgegeven in HTTP-instellingen, maar een FQDN is opgegeven als het doel voor een lid van een back-endpool SNI wordt ingesteld als de hostnaam van de invoer-FQDN van de client en de CN van het back-endcertificaat moet overeenkomen met deze hostnaam. SNI wordt ingesteld als de hostnaam van de invoer-FQDN van de client en de CN van het back-endcertificaat moet overeenkomen met deze hostnaam.

Volgende stappen

Nadat u meer hebt geleerd over end-to-end TLS, gaat u naar End-to-end TLS configureren met behulp van Application Gateway met PowerShell om een toepassingsgateway te maken met behulp van end-to-end TLS.