Dela via

Certifikat och App Service-miljön v2

  • Artikel

Viktigt!

Den här artikeln handlar om App Service-miljön v2, som används med isolerade App Service-planer. App Service-miljön v1 och v2 dras tillbaka från och med den 31 augusti 2024. Det finns en ny version av App Service-miljön som är enklare att använda och köra på kraftfullare infrastruktur. Om du vill veta mer om den nya versionen börjar du med Introduktion till App Service-miljön. Om du för närvarande använder App Service-miljön v1 följer du stegen i den här artikeln för att migrera till den nya versionen.

Från och med den 31 augusti 2024 gäller serviceavtal (SLA) och tjänstkrediter inte längre för App Service-miljön v1- och v2-arbetsbelastningar som fortsätter att vara i produktion eftersom de är tillbakadragna produkter. Avvecklingen av maskinvaran App Service-miljön v1 och v2 har påbörjats, vilket kan påverka tillgängligheten och prestandan för dina appar och data.

Du måste slutföra migreringen till App Service-miljön v3 omedelbart eller så kan dina appar och resurser tas bort. Vi försöker automatiskt migrera eventuella återstående App Service-miljön v1 och v2 på bästa sätt med hjälp av migreringsfunktionen på plats, men Microsoft gör inga anspråk eller garantier om programtillgänglighet efter automatisk migrering. Du kan behöva utföra manuell konfiguration för att slutföra migreringen och optimera ditt SKU-val för App Service-plan för att uppfylla dina behov. Om automatisk migrering inte är möjlig tas dina resurser och associerade appdata bort. Vi uppmanar dig starkt att agera nu för att undvika något av dessa extrema scenarier.

Om du behöver ytterligare tid kan vi erbjuda en respitperiod på 30 dagar för att slutföra migreringen. Mer information och för att begära den här respitperioden finns i översikten över respitperioden och gå sedan till Azure Portal och gå till migreringsbladet för var och en av dina App Service-miljön.

Den senaste informationen om App Service-miljön v1/v2-tillbakadragning finns i App Service-miljön v1- och v2-pensionsuppdateringen.

App Service-miljön (ASE) är en distribution av Azure App Service som körs i ditt virtuella Azure-nätverk (VNet). Den kan distribueras med en internettillgänglig programslutpunkt eller en programslutpunkt som finns i ditt virtuella nätverk. Om du distribuerar ASE med en internettillgänglig slutpunkt kallas distributionen för en extern ASE. Om du distribuerar ASE med en slutpunkt i ditt virtuella nätverk kallas distributionen för en ILB ASE. Du kan lära dig mer om ILB ASE från dokumentet Skapa och använda en ILB ASE .

ASE är ett enda klientsystem. Eftersom det är en enskild klientorganisation finns det vissa funktioner som endast är tillgängliga med en ASE som inte är tillgängliga i App Service för flera klienter.

ILB ASE-certifikat

Om du använder en extern ASE nås dina appar med <appnamn>.<asename.p.azurewebsites.net>. Som standard skapas alla ASE:er, även ILB ASE:er, med certifikat som följer det formatet. När du har en ILB ASE nås apparna baserat på det domännamn som du anger när du skapar ILB ASE. För att apparna ska kunna stödja TLS måste du ladda upp certifikat. Skaffa ett giltigt TLS/SSL-certifikat genom att använda interna certifikatutfärdare, köpa ett certifikat från en extern utfärdare eller använda ett självsignerat certifikat.

Det finns två alternativ för att konfigurera certifikat med din ILB ASE. Du kan ange ett standardcertifikat med jokertecken för ILB ASE eller ange certifikat på de enskilda webbapparna i ASE. Oavsett vilket val du väljer måste följande certifikatattribut konfigureras korrekt:

  • Ämne: Det här attributet måste anges till *.[ your-root-domain-here] för ett ILB ASE-certifikat med jokertecken. Om du skapar certifikatet för din app bör det vara [appname]. [your-root-domain-here]
  • Alternativt ämnesnamn: Det här attributet måste innehålla både .[ your-root-domain-here] och.scm.[ your-root-domain-here] för ILB ASE-certifikatet med jokertecken. Om du skapar certifikatet för din app bör det vara [appname]. [your-root-domain-here] och [appname].scm. [your-root-domain-here].

Som en tredje variant kan du skapa ett ILB ASE-certifikat som innehåller alla dina enskilda appnamn i SAN för certifikatet i stället för att använda en jokerteckenreferens. Problemet med den här metoden är att du måste känna till namnen på de appar som du lägger i ASE i förväg, eller så måste du fortsätta uppdatera ILB ASE-certifikatet.

Ladda upp certifikat till ILB ASE

När en ILB ASE har skapats i portalen måste certifikatet anges för ILB ASE. Tills certifikatet har angetts visar ASE en banderoll om att certifikatet inte har angetts.

Certifikatet som du laddar upp måste vara en .pfx-fil. När certifikatet har laddats upp finns det en tidsfördröjning på cirka 20 minuter innan certifikatet används.

Du kan inte skapa ASE och ladda upp certifikatet som en åtgärd i portalen eller ens i en mall. Som en separat åtgärd kan du ladda upp certifikatet med hjälp av en mall enligt beskrivningen i dokumentet Skapa en ASE från en mall .

Om du vill skapa ett självsignerat certifikat snabbt för testning kan du använda följande powershell-bit:

$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"

$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText

$fileName = "exportedcert.pfx"
Export-PfxCertificate -cert $certThumbprint -FilePath $fileName -Password $password

När du skapar ett självsignerat certifikat måste du se till att ämnesnamnet har formatet CN={ASE_NAME_HERE}_InternalLoadBalancingASE.

Programcertifikat

Appar som finns i en ASE kan använda appcentrerade certifikatfunktioner som är tillgängliga i apptjänsten för flera klientorganisationer. Dessa funktioner omfattar:

  • SNI-certifikat
  • IP-baserad SSL, som endast stöds med en extern ASE. En ILB ASE stöder inte IP-baserad SSL.
  • KeyVault-värdbaserade certifikat

Anvisningarna för att ladda upp och hantera dessa certifikat finns i Lägg till ett TLS/SSL-certifikat i Azure App Service. Om du bara konfigurerar certifikat så att de matchar ett anpassat domännamn som du har tilldelat till webbappen räcker det med dessa instruktioner. Om du laddar upp certifikatet för en ILB ASE-webbapp med standarddomännamnet anger du scm-webbplatsen i SAN för certifikatet som tidigare nämnts.

TLS-inställningar

Du kan konfigurera TLS-inställningen på appnivå.

Privat klientcertifikat

Ett vanligt användningsfall är att konfigurera din app som en klient i en klient-server-modell. Om du skyddar servern med ett privat CA-certifikat måste du ladda upp klientcertifikatet till din app. Följande instruktioner läser in certifikat till förtroendearkivet för de arbetare som appen körs på. Om du läser in certifikatet till en app kan du använda det med dina andra appar i samma App Service-plan utan att ladda upp certifikatet igen.

Så här laddar du upp certifikatet till din app i DIN ASE:

  1. Generera en .cer fil för certifikatet.
  2. Gå till den app som behöver certifikatet i Azure Portal
  3. Gå till SSL-inställningar i appen. Klicka på Ladda upp certifikat. Välj Offentlig. Välj Lokal dator. Ange ett namn. Bläddra och välj din .cer-fil . Välj ladda upp.
  4. Kopiera tumavtrycket.
  5. Gå till Programinställningar. Skapa en appinställning WEBSITE_LOAD_ROOT_CERTIFICATES med tumavtrycket som värde. Om du har flera certifikat kan du placera dem i samma inställning avgränsade med kommatecken och inga blanksteg som

84EC242A4EC7957817B8E48913E50953552DAFA6,6A5C65DC9247F762FE17BF8D4906E04FE6B31819

Certifikatet kommer att vara tillgängligt av alla appar i samma App Service-plan som appen, som konfigurerade den inställningen. Om du vill att den ska vara tillgänglig för appar i en annan App Service-plan måste du upprepa appinställningsåtgärden i en app i den App Service-planen. Kontrollera att certifikatet har angetts genom att gå till Kudu-konsolen och utfärda följande kommando i PowerShell-felsökningskonsolen:

dir cert:\localmachine\root

För att utföra testning kan du skapa ett självsignerat certifikat och generera en .cer fil med följande PowerShell:

$certificate = New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname "*.internal.contoso.com","*.scm.internal.contoso.com"

$certThumbprint = "cert:\localMachine\my\" + $certificate.Thumbprint
$password = ConvertTo-SecureString -String "CHANGETHISPASSWORD" -Force -AsPlainText

$fileName = "exportedcert.cer"
export-certificate -Cert $certThumbprint -FilePath $fileName -Type CERT