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 v2 dras tillbaka 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 v2 följer du stegen i den här artikeln för att migrera till den nya versionen.

Från och med den 29 januari 2024 kan du inte längre skapa nya App Service-miljön v2-resurser med någon av de tillgängliga metoderna, inklusive ARM/Bicep-mallar, Azure Portal, Azure CLI eller REST API. Du måste migrera till App Service-miljön v3 före den 31 augusti 2024 för att förhindra resursborttagning och dataförlust.

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 innehavare.

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 namn på ämne: 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 eller att du måste 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 är 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 App Service 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 din webbapp 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 enligt vad som antecknades tidigare.

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-portalen

  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 Program Instä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