Freigeben über

Zertifikate und die App Service-Umgebung v2

  • Artikel

Wichtig

In diesem Artikel wird die App Service-Umgebung v2 beschrieben, die mit Plänen vom Typ „App Service (isoliert)“ verwendet wird. App Service-Umgebung v1 und v2 wurden am 31. August 2024 eingestellt. Für die App Service-Umgebung steht eine neue Version zur Verfügung. Diese ist benutzerfreundlicher und basiert auf einer leistungsfähigeren Infrastruktur. Weitere Informationen zu dieser neuen Version finden Sie unter Einführung in die App Service-Umgebung. Wenn Sie derzeit App Service-Umgebung v1 verwenden, führen Sie die Schritte in diesem Artikel aus, um zur neuen Version zu migrieren.

Die Vereinbarung zum Servicelevel (Service Level Agreement, SLA) und Dienstguthaben gelten seit dem 31. August 2024 nicht mehr für Workloads der App Service-Umgebung v1 und v2, da es sich um eingestellte Produkte handelt. Die Außerbetriebnahme der Hardware für die App Service-Umgebung v1 und v2 hat begonnen. Dies kann sich auf die Verfügbarkeit und Leistung Ihrer Apps und Daten auswirken.

Sie müssen die Migration zur App Service-Umgebung v3 sofort abschließen, sonst werden Ihre Apps und Ressourcen möglicherweise gelöscht. Es wird versucht, alle verbleibenden App Service-Umgebungen v1 und v2 bestmöglich mithilfe des Features für die direkte Migration automatisch zu migrieren, doch Microsoft garantiert die Anwendungsverfügbarkeit nach der automatischen Migration nicht. Möglicherweise müssen Sie eine manuelle Konfiguration durchführen, um die Migration abzuschließen und Ihre SKU-Auswahl für den App Service-Plan auf Basis Ihrer Anforderungen zu optimieren. Wenn die automatische Migration nicht möglich ist, werden Ihre Ressourcen und zugehörigen App-Daten gelöscht. Sie sollten schnell handeln, um diese Szenarien zu vermeiden.

Wenn Sie mehr Zeit benötigen, können wir Ihnen eine einmalige Karenzzeit von 30 Tagen anbieten, damit Sie Ihre Migration abschließen können. Weitere Informationen auch zum Anfordern dieser Karenzzeit finden Sie in der Übersicht über die Karenzzeit. Navigieren Sie anschließend im Azure-Portal zum Blatt „Migration“ für jede Ihrer App Service-Umgebungen.

Die aktuellsten Informationen zur Einstellung der App Service Environment v1/v2 finden Sie im Update zur Einstellung der App Service Environment v1 und v2.

Die App Service-Umgebung (ASE) ist eine Bereitstellung des Azure App Service, die in Ihrem Azure Virtual Network (VNet) ausgeführt wird. Sie kann mit einem über das Internet zugänglichen Anwendungsendpunkt oder einem Anwendungsendpunkt in Ihrem virtuellen Netzwerk bereitgestellt werden. Wenn Sie die ASE mit einem über das Internet zugänglichen Endpunkt bereitstellen, wird diese Bereitstellung als externe ASE bezeichnet. Wenn Sie die ASE mit einem Endpunkt in Ihrem virtuellen Netzwerk bereitstellen, wird diese Bereitstellung als IBL-ASE bezeichnet. Weitere Informationen zur ILB-ASE finden Sie im Dokument Erstellen und Verwenden einer ILB-ASE.

Die ASE ist ein einzelnes Mandantensystem. Da es sich um einen einzelnen Mandanten handelt, gibt es einige Features, die nur mit einer ASE verfügbar sind und die in App Service mit mehreren Mandanten nicht verfügbar sind.

ILB-ASE-Zertifikate

Bei Verwendung einer externen ASE sind Ihre Apps unter „<App-Name>.<ASE-Name>.p.azurewebsites.net“ erreichbar. Standardmäßig werden alle ASEs, auch ILB-ASEs, mit Zertifikaten erstellt, die diesem Format folgen. Wenn Sie über eine ILB ASE verfügen, werden die Apps basierend auf dem Domänennamen erreicht, den Sie beim Erstellen der ILB-ASE angeben. Damit die Apps TLS unterstützen, müssen Sie Zertifikate hochladen. Ein gültiges TLS/SSL-Zertifikat können Sie erhalten, indem Sie interne Zertifizierungsstellen verwenden, ein Zertifikat von einem externen Aussteller erwerben oder ein selbstsigniertes Zertifikat verwenden.

Es gibt zwei Möglichkeiten, Zertifikate mit Ihrer ILB-ASE zu konfigurieren. Sie können ein Platzhalterzertifikat für die ILB-ASE festlegen oder Zertifikate für die einzelnen Web-Apps in der ASE festlegen. Unabhängig davon, welche Auswahl Sie treffen, müssen die folgenden Zertifikatsattribute ordnungsgemäß konfiguriert sein:

  • : Dieses Attribut muss für ein ILB-ASE-Platzhalterzertifikat auf *.[ihre-stammdomäne-hier] festgelegt werden. Wenn Sie das Zertifikat für Ihre App erstellen, dann sollte es [app-name].[ihre-stammdomäne-hier] lauten.
  • Alternativer Antragstellername: Dieses Attribut muss sowohl „.[Ihre-Stammdomäne]“ als auch „.scm.[Ihre-Stammdomäne]“ für das ILB-ASE-Platzhalterzertifikat enthalten. Wenn Sie das Zertifikat für Ihre App erstellen, dann sollte es [app-name].[ihre-stammdomäne-hier] und [app-name].scm.[ihre-stammdomäne-hier] lauten.

Als dritte Variante können Sie ein ILB-ASE-Zertifikat erstellen, das alle Ihre individuellen App-Namen im SAN des Zertifikats anstelle einer Platzhalterreferenz enthält. Das Problem bei dieser Methode ist, dass Sie im Voraus die Namen der Apps kennen müssen, die Sie in die ASE einfügen, oder dass Sie das ILB-ASE-Zertifikat ständig aktualisieren müssen.

Hochladen des Zertifikats in die ILB-ASE

Nachdem eine ILB-ASE im Portal erstellt wurde, muss das Zertifikat für die ILB-ASE festgelegt werden. Bis das Zertifikat festgelegt ist, wird in der ASE ein Banner angezeigt, dass das Zertifikat nicht festgelegt wurde.

Das Zertifikat, das Sie hochladen, muss eine PFX-Datei sein. Nach dem Hochladen des Zertifikats dauert es etwa 20 Minuten, bis das Zertifikat verwendet wird.

Sie können die Erstellung der ASE und das Hochladen des Zertifikats nicht als eine Aktion im Portal oder sogar in einer Vorlage durchführen. Als separate Aktion können Sie das Zertifikat mithilfe einer Vorlage hochladen, wie im Dokument Erstellen einer ASE aus einer Vorlage beschrieben.

Wenn Sie schnell ein selbstsigniertes Zertifikat zum Testen erstellen möchten, können Sie das folgende Element von PowerShell verwenden:

$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

Wenn Sie ein selbstsigniertes Zertifikat erstellen, müssen Sie sicherstellen, dass der Antragstellername das Format „CN={ASE_NAME}_InternalLoadBalancingASE“ hat.

Anwendungszertifikate

In einer ASE gehostete Apps können die anwendungsorientierten Zertifikatsfeatures nutzen, die in App Service mit mehreren Mandanten verfügbar sind. Zu den Features zählen:

  • SNI-Zertifikate
  • IP-basiertes SSL, das nur mit einer externen ASE unterstützt wird. Eine ILB-ASE unterstützt kein IP-basiertes SSL.
  • KeyVault-gehostete Zertifikate

Anweisungen zum Hochladen und Verwalten dieser Zertifikate finden Sie unter Hinzufügen eines TLS/SSL-Zertifikats in Azure App Service. Wenn Sie lediglich Zertifikate so konfigurieren, dass sie mit einem benutzerdefinierten Domänennamen übereinstimmen, den Sie Ihrer Web-App zugewiesen haben, reichen diese Anweisungen aus. Wenn Sie das Zertifikat für eine Web-App in einer ILB-ASE mit dem Standarddomänennamen hochladen, geben Sie die SCM-Website wie bereits erwähnt im SAN des Zertifikats an.

TLS-Einstellungen

Sie können die TLS-Einstellung auf App-Ebene konfigurieren.

Privates Clientzertifikat

Ein häufiger Anwendungsfall ist die Konfiguration Ihrer App als Client in einem Client/Server-Modell. Wenn Sie Ihren Server mit einem privaten CA-Zertifikat schützen, müssen Sie das Clientzertifikat in Ihre App hochladen. Die folgenden Anweisungen laden Zertifikate in den Truststore der Worker, in dem Ihre App ausgeführt wird. Wenn Sie das Zertifikat in eine App laden, können Sie es mit Ihren anderen Apps im gleichen App Service-Plan verwenden, ohne das Zertifikat erneut hochzuladen.

So laden Sie das Zertifikat in Ihre App in der ASE

  1. Generieren Sie eine CER-Datei für Ihr Zertifikat.
  2. Wechseln Sie zu der App im Azure-Portal, die das Zertifikat benötigt.
  3. Wechseln Sie zu den SSL-Einstellungen in der App. Klicken Sie auf „Zertifikat hochladen“. Wählen Sie „Öffentlich“ aus. Wählen Sie „Lokaler Computer“ aus. Geben Sie einen Namen ein. Navigieren Sie zu Ihrer CER-Datei und wählen Sie sie aus. Wählen Sie „Hochladen“ aus.
  4. Kopieren Sie den Fingerabdruck.
  5. Wechseln Sie zu den Anwendungseinstellungen. Erstellen Sie die Anwendungseinstellung WEBSITE_LOAD_ROOT_CERTIFICATES mit dem Fingerabdruck als Wert. Wenn Sie über mehrere Zertifikate verfügen, können Sie diese in derselben Einstellung einfügen, getrennt durch Kommas und ohne Leerzeichen wie

84EC242A4EC7957817B8E48913E50953552DAFA6,6A5C65DC9247F762FE17BF8D4906E04FE6B31819

Das Zertifikat steht allen Apps im gleichen App Service-Plan zur Verfügung wie die App, die diese Einstellung konfiguriert hat. Wenn es für Apps in einem anderen App Service-Plan verfügbar sein soll, müssen Sie den App-Einstellungsvorgang in einer App in diesem App Service-Plan wiederholen. Um zu überprüfen, ob das Zertifikat festgelegt ist, wechseln Sie zur Kudu-Konsole, und geben Sie den folgenden Befehl in die PowerShell-Debugkonsole ein:

dir cert:\localmachine\root

Sie können zum Testen ein selbstsigniertes Zertifikat erstellen und eine CER-Datei mit der folgenden PowerShell generieren:

$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