Delen via

End-to-end TLS met Azure Front Door

  • Artikel

Belangrijk

Ondersteuning voor TLS 1.0 en 1.1 wordt stopgezet op 1 maart 2025.

Transport Layer Security (TLS), voorheen bekend als SSL (Secure Sockets Layer), is de standaardbeveiligingstechnologie voor het tot stand brengen van een versleutelde koppeling tussen een webserver en een client, zoals een webbrowser. Deze koppeling zorgt ervoor dat alle gegevens die worden doorgegeven tussen de server en de client privé en versleuteld blijven.

Azure Front Door biedt ondersteuning voor end-to-end TLS-versleuteling om te voldoen aan uw beveiligings- of nalevingsvereisten. Front Door TLS/SSL offload beëindigt de TLS-verbinding, ontsleutelt het verkeer bij Azure Front Door en versleutelt het verkeer opnieuw voordat het naar de oorsprong wordt doorgestuurd. Wanneer verbindingen met de origin gebruikmaken van het openbare IP-adres van de origin, is het een goede beveiligingspraktijk om HTTPS te configureren als het doorstuurprotocol op uw Azure Front Door. Door HTTPS als het doorstuurprotocol te gebruiken, kunt u end-to-end TLS-versleuteling afdwingen voor de volledige verwerking van de aanvraag van de client naar de oorsprong. TLS/SSL-offload wordt ook ondersteund als u een privé-origin implementeert met Azure Front Door Premium met behulp van de functie Private Link .

In dit artikel wordt uitgelegd hoe Azure Front Door werkt met TLS-verbindingen. Zie HTTPS voor aangepaste domeinen voor meer informatie over het gebruik van TLS-certificaten met uw eigen aangepaste domeinen. Zie Een aangepast domein configureren in Azure Front Door met behulp van Azure Portal voor meer informatie over het configureren van een TLS-certificaat in uw eigen aangepaste domein.

End-to-end TLS-versleuteling

Met End-to-end TLS kunt u gevoelige gegevens beveiligen tijdens de overdracht naar de oorsprong, terwijl u profiteert van Azure Front Door-functies zoals wereldwijde taakverdeling en caching. Sommige functies omvatten ook routering op basis van URL's, TCP-splitsing, caching op edge-locatie die zich het dichtst bij de clients bevindt en het aanpassen van HTTP-aanvragen aan de rand.

Azure Front Door offload de TLS-sessies aan de rand en ontsleutelt clientaanvragen. Vervolgens worden de geconfigureerde routeringsregels toegepast om de aanvragen te routeren naar de juiste oorsprong in de oorspronkelijke groep. Azure Front Door start vervolgens een nieuwe TLS-verbinding met de oorsprong en versleutelt alle gegevens opnieuw met behulp van het certificaat van de oorsprong voordat de aanvraag naar de oorsprong wordt verzonden. Elk antwoord van de oorsprong wordt versleuteld via hetzelfde proces terug naar de eindgebruiker. U kunt uw Azure Front Door configureren voor het gebruik van HTTPS als het doorstuurprotocol om end-to-end TLS in te schakelen.

Ondersteunde TLS-versies

Azure Front Door ondersteunt momenteel vier versies van het TLS-protocol: TLS-versies 1.0, 1.1, 1.2 en 1.3. Alle Azure Front Door-profielen die na september 2019 zijn gemaakt, gebruiken TLS 1.2 als het standaard minimum met TLS 1.3 ingeschakeld, maar TLS 1.0 en TLS 1.1 worden nog steeds ondersteund voor achterwaartse compatibiliteit. Ondersteuning voor TLS 1.0 en 1.1 wordt stopgezet op 1 maart 2025.

Hoewel Azure Front Door TLS 1.2 ondersteunt, waardoor client-/wederzijdse verificatie is geïntroduceerd in RFC 5246, biedt Azure Front Door momenteel nog geen ondersteuning voor client-/wederzijdse verificatie (mTLS).

U kunt de minimale TLS-versie in Azure Front Door configureren in de HTTPS-instellingen van het aangepaste domein met behulp van Azure Portal of de Azure REST API. Op dit moment kunt u kiezen tussen 1.0 en 1.2. Als zodanig wordt tls 1.2 opgegeven als de minimale versie bepaalt welke minimaal acceptabele TLS-versie Azure Front Door van een client accepteert. Voor minimaal TLS-versie 1.2 probeert de onderhandeling TLS 1.3 en vervolgens TLS 1.2 tot stand te brengen, terwijl voor minimaal TLS-versie 1.0 alle vier de versies worden geprobeerd. Wanneer Azure Front Door TLS-verkeer naar de oorsprong initieert, wordt geprobeerd om te onderhandelen over de beste TLS-versie die de oorsprong betrouwbaar en consistent kan accepteren. Ondersteunde TLS-versies voor oorspronkelijke verbindingen zijn TLS 1.0, TLS 1.1, TLS 1.2 en TLS 1.3. Ondersteuning voor TLS 1.0 en 1.1 wordt stopgezet op 1 maart 2025.

Notitie

  • Clients waarvoor TLS 1.3 is ingeschakeld, zijn vereist voor ondersteuning van een van de Microsoft SDL-compatibele EC-curven, waaronder Secp384r1, Secp256r1 en Secp521, om aanvragen met Azure Front Door te kunnen indienen met behulp van TLS 1.3.
  • Het wordt aanbevolen dat clients een van deze curven gebruiken als hun voorkeurscurve tijdens aanvragen om verhoogde TLS-handshakelatentie te voorkomen. Dit kan het gevolg zijn van meerdere retouren om te onderhandelen over de ondersteunde EC-curve.

Ondersteunde certificaten

Wanneer u uw TLS/SSL-certificaat maakt, moet u een volledige certificaatketen maken met een toegestane certificeringsinstantie (CA) die deel uitmaakt van de lijst met vertrouwde MICROSOFT-CA's. Als u een niet-toegestane CA gebruikt, wordt uw aanvraag geweigerd.

Certificaten van interne CA's of zelfondertekende certificaten zijn niet toegestaan.

OCSP-koppeling (Online Certificate Status Protocol)

OCSP-koppeling wordt standaard ondersteund in Azure Front Door en er is geen configuratie vereist.

TLS-verbinding van oorsprong (Azure Front Door naar origin)

Voor HTTPS-verbindingen verwacht Azure Front Door dat uw oorsprong een certificaat van een geldige certificeringsinstantie (CA) presenteert met een onderwerpnaam die overeenkomt met de hostnaam van de oorsprong. Als uw oorspronkelijke hostnaam is ingesteld op myapp-centralus.contosonews.net en het certificaat dat uw oorsprong presenteert tijdens de TLS-handshake niet over de onderwerpnaam beschikt myapp-centralus.contosonews.net , *.contosonews.net weigert Azure Front Door de verbinding en ziet de client een fout.

Notitie

Het certificaat moet een volledige certificaatketen met leaf- en tussenliggende certificaten hebben. De basis-CA moet deel uitmaken van de lijst met vertrouwde MICROSOFT-CA's. Als er een certificaat zonder volledige keten wordt weergegeven, werken de aanvragen die betrekking hebben op dat certificaat niet gegarandeerd zoals verwacht.

In bepaalde gebruiksscenario's, zoals voor testen, kunt u, als tijdelijke oplossing voor het oplossen van een mislukte HTTPS-verbinding, de controle van de onderwerpnaam van het certificaat uitschakelen voor uw Azure Front Door. Houd er rekening mee dat de oorsprong nog steeds een certificaat moet presenteren met een geldige vertrouwde keten, maar niet moet overeenkomen met de hostnaam van de oorsprong.

In Azure Front Door Standard en Premium kunt u een oorsprong configureren om de controle van de onderwerpnaam van het certificaat uit te schakelen.

In Azure Front Door (klassiek) kunt u de controle van de onderwerpnaam van het certificaat uitschakelen door de Azure Front Door-instellingen in Azure Portal te wijzigen. U kunt de controle ook configureren met behulp van de instellingen van de back-endpool in de Azure Front Door-API's.

Notitie

Vanuit het oogpunt van beveiliging raadt Microsoft niet aan de controle van de onderwerpnaam van het certificaat uit te schakelen.

Front-end TLS-verbinding (client naar Azure Front Door)

Als u het HTTPS-protocol wilt inschakelen voor veilige levering van inhoud in een aangepast Azure Front Door-domein, kunt u ervoor kiezen om een certificaat te gebruiken dat wordt beheerd door Azure Front Door of uw eigen certificaat gebruiken.

Zie HTTPS voor aangepaste domeinen voor meer informatie.

Het beheerde certificaat van Azure Front Door biedt een standaard TLS/SSL-certificaat via DigiCert en wordt opgeslagen in De Key Vault van Azure Front Door.

Als u ervoor kiest om uw eigen certificaat te gebruiken, kunt u een certificaat onboarden vanaf een ondersteunde CA die een standaard TLS-, uitgebreid validatiecertificaat of zelfs een jokertekencertificaat kan zijn. Zelfondertekende certificaten worden niet ondersteund. Meer informatie over het inschakelen van HTTPS voor een aangepast domein.

Automatischerotatie van certificaat

Voor de door Azure Front Door beheerde certificaatoptie worden de certificaten beheerd en worden ze binnen 90 dagen na verlooptijd automatisch gedraaid door Azure Front Door. Voor de optie voor het beheerde Azure Front Door Standard-/Premium-certificaat worden de certificaten beheerd en worden ze binnen 45 dagen na verlooptijd automatisch gedraaid door Azure Front Door. Als u een beheerd Azure Front Door-certificaat gebruikt en ziet dat de vervaldatum van het certificaat minder dan 60 dagen verwijderd is of 30 dagen voor de Standard/Premium-SKU, dient u een ondersteuningsticket in.

Voor uw eigen aangepaste TLS/SSL-certificaat:

  1. U stelt de geheime versie in op 'Nieuwste' om het certificaat automatisch te draaien naar de nieuwste versie wanneer er een nieuwere versie van het certificaat beschikbaar is in uw sleutelkluis. Voor aangepaste certificaten wordt het certificaat binnen 3-4 dagen automatisch gedraaid met een nieuwere versie van het certificaat, ongeacht de verlopen tijd van het certificaat.

  2. Als er een specifieke versie is geselecteerd, wordt automatischerotatie niet ondersteund. U moet de nieuwe versie handmatig opnieuw selecteren om het certificaat te roteren. Het duurt maximaal 24 uur voordat de nieuwe versie van het certificaat/geheim is geïmplementeerd.

    Notitie

    Beheerde certificaten van Azure Front Door (Standard en Premium) worden automatisch geroteerd als de domein-CNAME-record rechtstreeks naar een Front Door-eindpunt verwijst of indirect verwijst naar een Traffic Manager-eindpunt. Anders moet u het eigendom van het domein opnieuw valideren om de certificaten te roteren.

    U moet ervoor zorgen dat de service-principal voor Front Door toegang heeft tot de sleutelkluis. Raadpleeg hoe u toegang verleent tot uw sleutelkluis. De bijgewerkte implementatiebewerking van het certificaat door Azure Front Door veroorzaakt geen downtime voor productie, zolang de onderwerpnaam of alternatieve onderwerpnaam (SAN) voor het certificaat niet is gewijzigd.

Ondersteunde coderingssuites

Voor TLS 1.2/1.3 worden de volgende coderingssuites ondersteund:

  • TLS_AES_256_GCM_SHA384 (alleen TLS 1.3)
  • TLS_AES_128_GCM_SHA256 (alleen 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

Notitie

Voor Windows 10- en latere versies raden we u aan om een of beide ECDHE_GCM coderingssuites in te schakelen voor betere beveiliging. Windows 8.1, 8 en 7 zijn niet compatibel met deze ECDHE_GCM coderingssuites. De ECDHE_CBC- en DHE-coderingssuites zijn voorzien voor compatibiliteit met die besturingssystemen.

Wanneer aangepaste domeinen worden gebruikt met TLS 1.0 en 1.1 ingeschakeld, worden de volgende coderingssuites ondersteund:

  • TLS_AES_256_GCM_SHA384 (alleen TLS 1.3)
  • TLS_AES_128_GCM_SHA256 (alleen 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 biedt geen ondersteuning voor het uitschakelen of configureren van specifieke coderingssuites voor uw profiel.

Volgende stappen