Delen via

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 worden doorgegeven tussen de webserver en browsers 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 doorgaans niet-versleuteld naar de back-endservers stroomt. Er zijn een aantal voordelen van het uitvoeren van TLS-beëindiging bij de toepassingsgateway:

  • Verbeterde prestaties : de grootste prestatietreffer bij het uitvoeren van TLS-ontsleuteling is de eerste handshake. Om de prestaties te verbeteren, slaat de server met de ontsleuteling TLS-sessie-id's in de cache op en beheert tls-sessietickets. Als dit gebeurt op de toepassingsgateway, kunnen alle aanvragen van dezelfde client de waarden in de cache gebruiken. Als dit gebeurt op de back-endservers, moet telkens wanneer de aanvragen van de client naar een andere server worden verzonden, de client opnieuw verifiëren. Het gebruik van TLS-tickets kan helpen dit probleem te verhelpen, maar ze worden niet ondersteund door alle clients en kunnen moeilijk te configureren en beheren zijn.
  • Beter gebruik van de back-endservers : SSL/TLS-verwerking is zeer CPU-intensief en wordt steeds intensiever naarmate de sleutelgrootten toenemen. Door dit werk van de back-endservers te verwijderen, kunnen ze zich richten op wat ze het meest efficiënt zijn en inhoud leveren.
  • Intelligente routering : door het verkeer te ontsleutelen, heeft de toepassingsgateway toegang tot de aanvraaginhoud, zoals headers, URI, enzovoort, en kan deze gegevens gebruiken 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 application gateway binnenkomend verkeer ontsleutelen en antwoordverkeer naar de client versleutelen. Het certificaat dat aan de Application Gateway wordt verstrekt, moet de PFX-indeling (Personal Information Exchange) hebben, die zowel de persoonlijke als openbare sleutels bevat. De ondersteunde PFX-algoritmen worden vermeld op de functie PFXImportCertStore.

Belangrijk

Voor het certificaat op de listener moet de volledige certificaatketen worden geüpload (het basiscertificaat van de CA, de tussenliggende 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.

Als de TLS-verbinding werkt, moet u ervoor zorgen dat het TLS/SSL-certificaat aan de volgende voorwaarden voldoet:

  • Dat de huidige datum en tijd binnen het datumbereik Geldig van en Geldig tot op het certificaat valt.
  • 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 van het back-endcertificaat (CN), 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 (Extended Validation): een EV-certificaat is een certificaat dat voldoet aan de richtlijnen voor industriestandaardcertificaten. Hiermee wordt de browserzoekerbalk groen en wordt ook de bedrijfsnaam gepubliceerd.
  • Wildcard-certificaat: dit certificaat ondersteunt een willekeurig aantal subdomeinen op basis van *.site.com, waarbij uw subdomein het *zou vervangen. Het biedt echter geen ondersteuning voor site.com, dus als de gebruikers toegang hebben tot uw website zonder het toonaangevende 'www' te typen, wordt dat niet behandeld door het jokertekencertificaat.
  • Zelfondertekende 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 testen of omgevingen waar 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 Limieten voor Application Gateway om te weten wat de maximale ondersteunde TLS/SSL-certificaatgrootte is.

End-to-end TLS-versleuteling

Mogelijk wilt u geen niet-versleutelde communicatie met de back-endservers. Mogelijk hebt u beveiligingsvereisten, nalevingsvereisten of kan de toepassing alleen een beveiligde verbinding accepteren. Azure-toepassing 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 laag-7-taakverdelingsfuncties van Application Gateway gebruikt. Deze functies omvatten sessieaffiniteit op basis van cookies, URL-gebaseerde routering, ondersteuning voor routering op basis van sites, de mogelijkheid om X-Forwarded-*-headers te herschrijven of te injecteren, enzovoort.

Wanneer Application Gateway is geconfigureerd met de end-to-end TLS-communicatiemodus, worden de TLS-sessies op de gateway beëindigd en wordt het gebruikersverkeer ontsleuteld. 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 initieert 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-end wordt verzonden. Reacties van de webserver ondergaan hetzelfde proces terug naar de eindgebruiker. End-to-end TLS wordt ingeschakeld door protocolinstelling in de BACK-end-HTTP-instelling in te stellen op HTTPS, die vervolgens wordt toegepast op een back-endpool.

In Application Gateway v1 SKU-gateways past TLS-beleid alleen de TLS-versie 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, worden tls-verbindingen voor back-end altijd onderhandeld via TLS 1.0 naar TLS 1.2-versies.

Application Gateway communiceert alleen met de back-endservers die hun certificaat toestaan met de Application Gateway of waarvan de certificaten zijn ondertekend door bekende CA-autoriteiten en de CN van het certificaat overeenkomt met de hostnaam in de HTTP-back-endinstellingen. Dit zijn 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 veilige communicatie mogelijk te maken. Door het certificaat toe te voegen, zorgt u ervoor dat de toepassingsgateway alleen communiceert met bekende back-endinstanties. Hierdoor wordt de end-to-end communicatie verder beveiligd.

Notitie

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

end to end TLS scenario

In dit voorbeeld worden aanvragen met behulp van TLS1.2 doorgestuurd 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 die hun certificaat toestaan met de Application Gateway of waarvan de certificaten zijn ondertekend door bekende CA-autoriteiten en de CN van het certificaat overeenkomt met de hostnaam in de HTTP-back-endinstellingen. Er zijn enkele verschillen in het end-to-end TLS-installatieproces met betrekking tot de versie van Application Gateway die wordt gebruikt. In de volgende sectie worden de versies afzonderlijk uitgelegd.

End-to-end TLS met de v1-SKU

Als u end-to-end TLS wilt inschakelen met de back-endservers en application Gateway om aanvragen naar hen te routeren, moeten de statustests slagen en een goede reactie 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 vervolgens 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 toegestaan met de toepassingsgateway, zoals beschreven in de voorgaande stappen voordat ze kunnen worden gebruikt.

Notitie

Verificatie en installatie van 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 INSTELLINGEN van de HTTP-back-end, hoeven geen extra stappen te worden uitgevoerd voor end-to-end TLS.

    Als de back-endcertificaten bijvoorbeeld worden uitgegeven door een bekende CA en een CN van contoso.com heeft en het hostveld van de back-end-HTTP-instelling ook is ingesteld op contoso.com, zijn er geen extra stappen vereist. U kunt het http-instellingsprotocol voor de back-end instellen op HTTPS en zowel de statustest als het gegevenspad zijn ingeschakeld voor TLS. 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

Om een TLS/SSL-certificaat te kunnen vertrouwen, moet dat certificaat van de back-endserver zijn uitgegeven door een certificeringsinstantie die bekend is. Als het certificaat niet is uitgegeven door een vertrouwde CERTIFICERINGsinstantie, controleert de toepassingsgateway of het certificaat van de verlenende CA is uitgegeven door een vertrouwde CA, enzovoort totdat een vertrouwde CA is gevonden (op welk moment een vertrouwde, beveiligde verbinding tot stand is gebracht) of er geen vertrouwde CA kan worden gevonden (op welk moment de toepassingsgateway de back-end in orde markeert). Daarom wordt het aanbevolen het back-endservercertificaat zowel de basis- als tussenliggende CA's te bevatten.

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

  • Naast de overeenkomst met het basiscertificaat controleert 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 gepresenteerd 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 de hostnaam van het back-enddoel wordt gekozen 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 de CN op de TLS/SSL-certificaat van de back-endserver overeenkomen met de FQDN. Leden van back-endpools met IP-adressen worden in dit scenario niet ondersteund.

  • 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 het de front-endverbinding noemen), ontsleutelt het verkeer, past de benodigde regels toe om de back-endserver te bepalen waarop de aanvraag moet worden doorgestuurd en wordt een nieuwe TLS-sessie met de back-endserver tot stand gebracht (laten we het de back-endverbinding noemen).

De volgende tabellen geven een overzicht van de verschillen in SNI tussen de v1- en v2-SKU in termen van front-end- en back-endverbindingen.

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 aanvraagrouteringsregels 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 regels voor aanvraagroutering 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 naar de client (standaardcertificaat of terugvalcertificaat) Retourneert het certificaat dat is geconfigureerd in de basislistener

Fooi

De SNI-vlag kan worden geconfigureerd met PowerShell of met behulp van een ARM-sjabloon. Zie RequireServerNameIndication en Quickstart: Webverkeer omleiden met Azure-toepassing Gateway - ARM-sjabloon voor meer informatie.

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

Voor testverkeer

Scenario v1 v2
SNI-header (server_name) tijdens de TLS-handshake als FQDN Instellen 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 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 in de back-endpool wordt vermeld. De volgorde van prioriteit is aangepaste > back-endpool voor http-instellingen > voor tests.
Opmerking: Als de hostnamen die zijn geconfigureerd in HTTP-instellingen en aangepaste tests verschillen, wordt SNI ingesteld als de hostnaam van de aangepaste test.
Als het adres van de back-endpool een IP-adres (v1) is of als de hostnaam van de aangepaste test is geconfigureerd als IP-adres (v2) SNI (server_name) wordt niet ingesteld.
Opmerking: In dit geval moet de back-endserver een standaardcertificaat/terugvalcertificaat kunnen retourneren en moet dit worden toegestaan in 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 werd vermeld, als ze een 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 een aangepaste test niet 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 hier genoemde 127.0.0.1 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 Instellen 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 van de HTTP-instellingen, anders, als de optie PickHostnameFromBackendAddress is 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 of hostnaam is, niet is ingesteld in 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 er wordt een FQDN opgegeven als doel voor een lid van de 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.