@DanijelMalik , Danke für dein Feedback. Wir prüfen diese Anfrage und werden Sie so schnell wie möglich aktualisieren.

@DanijelMalik , Bitte geben Sie uns die Powershell-Ausgabe für diesen Fehler. Welche ähnlich aussehen,
Hinweis: Bitte achten Sie darauf, vertrauliche Bereiche wie Abonnement-ID oder Geheimnisse zu maskieren.
{
"Status": "Fehlgeschlagen",
"Error": {
"code": "ApplicationGatewayKeyVaultSecretException",
"message": "Beim Zugriff auf und bei der Validierung von KeyVault-Geheimnissen im Zusammenhang mit Application Gateway ist ein Problem aufgetreten.
"Einzelheiten": [
{
"code": "ApplicationGatewayKeyVaultSecretAccessDenied",
"message": "Zugriff verweigert für KeyVault Secret 'XXXXXXXXXXXXXXXXX' für Application Gateway '/subscriptions/XXXXXXXXXXX/resourceGroups/XXXXXXXXXXXXX/providers/Microsoft.Network/applicationGateways/applicationGatewat mit Geheimnis verbunden. "
}}
]]
}}
}}

@DanijelMalik , Überprüfe nur, ob du etwas Zeit hast, um die vorherige Antwort anzuzeigen.

@DanijelMalik , Da wir noch nichts von Ihnen gehört haben, werden wir diesen Thread nun schließen. Wenn Sie weitere Fragen zu diesem Thema haben, markieren Sie mich bitte in Ihrer Antwort. Wir werden das Thema gerne wieder eröffnen und die Diskussion fortsetzen.

Gleiches Problem hier.

Für mich wurde dies behoben, indem das weiche Löschen auf dem Schlüsseldepot aktiviert wurde.

Es gibt ein Problem, dass diese Anforderung nicht dokumentiert ist: # 34382

Hallo, ich habe das gleiche Problem. Das Problem scheint zu sein, dass der Keyvault zwar den Zugriff über das AppGw-Subnetz ermöglicht (über das Blade für Einstellungen für Firewalls und virtuelle Netzwerke in der Keyvault-Konfiguration). und das appGw-Subnetz wird über das Argument -GatewayIpConfigurations in New-AzApplicationGateway eingegeben. Das appGw scheint nicht auf den Keyvault zugreifen zu können (die Identität hat auch Zugriffsrechte in den Keyvault-Zugriffsrichtlinien).

Wenn ich den Zugriff auf den Schlüsseltresor von "allen Netzwerken" aus erlaube, scheint es gut zu funktionieren.

Möglicherweise wird beim Erstellen von appGw auf den Keyvault zugegriffen, bevor das AppGw mit dem Subnetz konfiguriert wird und der Keyvault diesen Zugriff dann von einem anderen Ort als dem Subnetz aus sieht.

Ich führe das Powershell-Skript lokal aus, aber meine IP hat auch Zugriff auf den Schlüsseldepot, sodass dies nicht das Problem sein sollte.

Ich sehe das gleiche Problem

@ SubhashVasarapu-MSFT

Ich habe das gleiche Problem. Ich verwende Azure CLI 2.0.76. Mein Anwendungsgateway und mein Schlüsseldepot befinden sich in verschiedenen Ressourcengruppen im selben Abonnement. Der Schlüsseltresor hat das weiche Löschen aktiviert, kann von allen Netzwerken aus aufgerufen werden und verfügt über eine Zugriffsrichtlinie für die dem Anwendungsgateway zugewiesene vom Benutzer zugewiesene Identität mit der Berechtigung "Geheimnisse abrufen".

az network application-gateway ssl-cert create -g XXX --gateway-name XXX --name XXX --key-vault-secret-id https://XXX.vault.azure.net/secrets/XXX --debug

Ergebnisse in (abgekürzt)

msrest.http_logger : {
  "status": "Failed",
  "error": {
    "code": "ApplicationGatewayKeyVaultSecretException",
    "message": "Problem occured while accessing and validating KeyVault Secrets associated with Application Gateway '/subscriptions/XXX/resourceGroups/XXX/providers/Microsoft.Network/applicationGateways/XXX'. See details below:",
    "details": [
      {
        "code": "ApplicationGatewayKeyVaultSecretAccessDenied",
        "message": "Access denied for KeyVault Secret 'https://XXX.vault.azure.net/secrets/XXX' for Application Gateway '/subscriptions/XXX/resourceGroups/XXX/providers/Microsoft.Network/applicationGateways/XXX'. Make sure that Identity assigned to Application Gateway has access to the KeyVault associated with secret."
      }
    ]
  }
}
msrest.exceptions : Problem occured while accessing and validating KeyVault Secrets associated with Application Gateway '/subscriptions/XXX/resourceGroups/XXX/providers/Microsoft.Network/applicationGateways/XXX'. See details below:
cli.azure.cli.core.util : Deployment failed. Correlation ID: 623f5539-b652-49fc-9a29-326bcadaa055. Access denied for KeyVault Secret 'https://XXX.vault.azure.net/secrets/XXX' for Application Gateway '/subscriptions/XXX/resourceGroups/XXX/providers/Microsoft.Network/applicationGateways/XXX'. Make sure that Identity assigned to Application Gateway has access to the KeyVault associated with secret.
Deployment failed. Correlation ID: 623f5539-b652-49fc-9a29-326bcadaa055. Access denied for KeyVault Secret 'https://XXX.vault.azure.net/secrets/XXX' for Application Gateway '/subscriptions/XXX/resourceGroups/XXX/providers/Microsoft.Network/applicationGateways/XXX'. Make sure that Identity assigned to Application Gateway has access to the KeyVault associated with secret.

Wenn ich den HTTP-Listener für das Anwendungsgateway in Azure Portal bearbeite und versuche, das SSL-Zertifikat vom dortigen Schlüsseldepot abzurufen, wird folgende Fehlermeldung angezeigt:

Konfigurationsänderungen am Anwendungsgateway 'XXX' konnten nicht gespeichert werden. Fehler: Ungültiger Wert für die Identitäten 'XXX / provider / Microsoft.ManagedIdentity / userAssignedIdentities / XXX'. Die Eigenschaftsschlüssel 'UserAssignedIdentities' sollten nur leere JSON-Objekte, null oder die vorhandene Ressource sein.

Hallo, ich habe das gleiche Problem. Das Problem scheint zu sein, dass der Keyvault zwar den Zugriff über das AppGw-Subnetz ermöglicht (über das Blade für Einstellungen für Firewalls und virtuelle Netzwerke in der Keyvault-Konfiguration). und das appGw-Subnetz wird über das Argument -GatewayIpConfigurations in New-AzApplicationGateway eingegeben. Das appGw scheint nicht auf den Keyvault zugreifen zu können (die Identität hat auch Zugriffsrechte in den Keyvault-Zugriffsrichtlinien).

Wenn ich den Zugriff auf den Schlüsseltresor von "allen Netzwerken" aus erlaube, scheint es gut zu funktionieren.

Möglicherweise wird beim Erstellen von appGw auf den Keyvault zugegriffen, bevor das AppGw mit dem Subnetz konfiguriert wird und der Keyvault diesen Zugriff dann von einem anderen Ort als dem Subnetz aus sieht.

Ich führe das Powershell-Skript lokal aus, aber meine IP hat auch Zugriff auf den Schlüsseldepot, sodass dies nicht das Problem sein sollte.

Das hat auch bei mir funktioniert. Die einzige Änderung, die ich vom Scheitern zum Erfolg vorgenommen habe, war, alle Netzwerke zuzulassen

Wenn ich den HTTP-Listener für das Anwendungsgateway in Azure Portal bearbeite und versuche, das SSL-Zertifikat vom dortigen Schlüsseldepot abzurufen, wird folgende Fehlermeldung angezeigt:

Konfigurationsänderungen am Anwendungsgateway 'XXX' konnten nicht gespeichert werden. Fehler: Ungültiger Wert für die Identitäten 'XXX / provider / Microsoft.ManagedIdentity / userAssignedIdentities / XXX'. Die Eigenschaftsschlüssel 'UserAssignedIdentities' sollten nur leere JSON-Objekte, null oder die vorhandene Ressource sein.

@ Wolfganggallo Ich bekomme genau den gleichen Fehler. Mein Azure-Portal scheint jetzt ebenfalls in einem Fehlerzustand zu stecken und lässt mich keine Änderungen vornehmen. Haben Sie es geschafft, dies zu beheben?

Att: @ SubhashVasarapu-MSFT - bitte wieder öffnen.

Ich erhalte das gleiche Problem: "_Die Eigenschaftsschlüssel 'UserAssignedIdentities' sollten nur leere JSON-Objekte sein, null oder die Ressource, die property_ existiert, und my - keyvault in einer anderen Ressourcengruppe und einem anderen vnet. Ich denke in meinem Fall die vnets werden nicht überprüft, sodass zur Laufzeit keine Route zwischen der APIM-Instanz und dem Keyvault besteht. In der Azure Portal-Benutzeroberfläche wird der Keyvault jedoch weiterhin als verfügbar aufgeführt und kann mit dem Listener verknüpft werden Temporäres vnet-Peering, um festzustellen, ob das Problem behoben ist, damit ich den Listener entfernen kann. Mein Appgw ist derzeit als Ergebnis defekt:

UPDATE Ja, das ist das Problem. Das Azure-Portal zeigt Ihnen wichtige Tresore an, die zur Laufzeit nicht verfügbar sind. Wenn Sie die Einstellungen des Listeners speichern, wird Ihr Appgw beschädigt. Die schnelle Lösung besteht darin, zum Keyvault zu gehen und ihn vorübergehend für "alle Netzwerke / Internet" zu öffnen und dann Ihren Listener erneut zu speichern. Was Sie dann tun, liegt bei Ihnen - kopieren Sie das Zertifikat in einen lokalen Schlüsseltresor, fügen Sie ein vnet-Peering hinzu oder fügen Sie das fehlende Subnetz hinzu. Letztendlich sollte das Portal die Netzwerkzugänglichkeit zwischen appgw und dem kyvault überprüfen. Fehler.

2. UPDATE Nur um klar zu sein: Dies bricht die Portal-Benutzeroberfläche vollständig. AppGw kann nicht über das Portal repariert werden. Nachfolgende Speicherungen schlagen fehl.

Ich habe diesen Fehler auch in der Portal-Benutzeroberfläche festgestellt. Soft Delete ist aktiviert. Das Umgehen aller Netzwerke hat funktioniert.

Bitte öffnen Sie erneut. Die Verwendung der Whitelist ist eine gute Sicherheit.

@ SubhashVasarapu-MSFT Bitte wieder öffnen. Wir haben es mit einem ähnlichen Problem zu tun. Die Benutzeroberfläche des Portals ist vollständig defekt.

Jeder Vorgang schlägt mit der folgenden Meldung fehl:
Set-AzApplicationGateway : Either Data or KeyVaultSecretId must be specified for Certificate '/subscriptions/********-****-****-****-************/resourceGroups/**-***-ApplicationGateway-RG/providers/Microsoft.Network/ applicationGateways/**-***-Shared-WAF/sslCertificates/wildcard2022' in Application Gateway.

@PgInsight @oising Mussten Sie nur "Alle Netzwerke zulassen" einstellen, damit AppGw wieder funktioniert? Wir haben ein Problem mit denselben Symptomen, aber wir haben den KeyVault im selben Subnetz, möglicherweise eine andere Grundursache.

Ich kann mit UI, PowerShell, CLI oder Resource Explorer nichts tun.

@PgInsight @oising Mussten Sie nur "Alle Netzwerke zulassen" einstellen, damit AppGw wieder funktioniert? Wir haben ein Problem mit denselben Symptomen, aber wir haben den KeyVault im selben Subnetz, möglicherweise eine andere Grundursache.

Ich kann mit UI, PowerShell, CLI oder Resource Explorer nichts tun.

Festlegen aller Netzwerke Zulassen auf dem KeyVault und wir mussten auch das Soft Delete-Flag auf dem Key Vault mit PowerShell cmd setzen.

($resource = Get-AzureRmResource -ResourceId (Get-AzureRmKeyVault -VaultName "YOUR-VAULT-NAME").ResourceId).Properties | Add-Member -MemberType "NoteProperty" -Name "enableSoftDelete" -Value "true"

Set-AzureRmResource -resourceid $resource.ResourceId -Properties $resource.Properties

Ich hatte das gleiche Problem. Ich konnte das Problem jedoch lösen, indem ich das Key Vault-Zertifikat mit PowerShell entfernte und nicht den Ressourcen-Explorer mit dem Explorer den folgenden Fehler anzeigte:
{
"Error": {
"code": "MissingIdentityIds",
"message": "Die Identitäts-IDs dürfen für den Identitätstyp 'UserAssigned' nicht null oder leer sein."
}}

}}

Verwenden Sie das folgende Beispielskript, um Zertifikat und Listener zu entfernen, und das App-Gateway wurde wieder in den Betriebszustand versetzt

Listener und Zertifikat aus App gw löschen

$ AppGw = Get-AzApplicationGateway -Name "app-gw-ssl-key" -ResourceGroupName "lab"
Remove-AzApplicationGatewayHttpListener -ApplicationGateway $ AppGw -Name "https"
Remove-AzApplicationGatewaySslCertificate -ApplicationGateway $ AppGW -Name "victor-cer"

Änderungen speichern

set-azapplicationgateway -ApplicationGateway $ AppGW

Wenn sich das App-Gateway außerhalb des Status "Fehlgeschlagen" befand, überprüfte ich die Zugriffsrichtlinie des Schlüsseldepots und stellte fest, dass sich die Identität des App-GW in einer anderen Kategorie befand, die nicht "ANWENDUNG" ist. Ich denke, das war die Ursache des Problems.
Die Identität wurde der Zugriffsrichtlinie über die Schlüsseldepoteinstellung erneut hinzugefügt und konnte als "ANWENDUNG" angezeigt werden. Dies löste das Problem für mich und ich konnte Listener mit Zertifikat aus Key Vault ohne Probleme hinzufügen.

@ SubhashVasarapu-MSFT Dies muss erneut geöffnet werden. Das App Gateway sollte niemals in einem deaktivierten / defekten Zustand wie diesem enden - ich habe das gleiche Problem erneut festgestellt. Wie kann dies eskaliert werden? Dies ist kein Dokumentationsproblem. Dies ist ein Problem mit der Produktqualität.

Zusammenfassen:

Wenn Sie einen Listener für die Verwendung eines SSL-Zertifikats in einem Remote-Keyvault konfigurieren, können Sie über die Portal-Benutzeroberfläche den Listener mit einem Keyvault konfigurieren, der zur Laufzeit für die AppGW aufgrund von Netzwerkeinschränkungen nicht verfügbar ist (nicht für das Internet geöffnet, nur ausgewählte Subnetze). Danach ist die App Gateway-Portaloberfläche für alle Listener GEBROCHEN.

Ich werde dies an das jeweilige Team weiterleiten.

Wie ist der Status davon?

Wir haben eine der Ursachen für diesen Fehler mit dem PG gefunden. Wenn Sie die Aufbewahrungsfrist für KeyVault auf einen anderen Wert als den Standardwert von 90 Tagen festgelegt haben, hat AppGW diese Fehlermeldung ausgegeben, auch wenn Sie Soft-Delete aktiviert und das gesamte Netzwerk als Eingabehilfen festgelegt haben. Das Update wird derzeit eingeführt, um diesen Fehler zu beheben.

Wann wird es eingeführt? Ich bin auch auf dieses Problem gestoßen, und es ist wirklich ein großes Problem, wenn Sie Portal nicht mehr konfigurieren oder ändern können, wenn Sie einmal darauf gestoßen sind.

Schlagen Sie dies heute einfach. Dieser Thread wurde gefunden, nachdem die Aufbewahrungsdauer für das Löschen auf 30 Tage festgelegt wurde und Sie ihn nicht ändern können. Würde es lieben, dieses Update auszurollen.

Ich habe genau das gleiche Problem, auch wenn die Standardaufbewahrungsfrist 90 Tage beträgt .
Unabhängig davon, ob Azure CLI, Powershell, TerraForm oder Portal ausgeführt werden, wird immer der gleiche Fehler angezeigt: "Beim Zugriff auf und bei der Überprüfung von KeyVault Secrets im Zusammenhang mit Application Gateway ist ein Problem aufgetreten ...".

Triple überprüfte die Identitäts- und Zugriffsrichtlinien, alle Ressourcen in derselben Ressourcengruppe am Standort "Westeuropa".

@ CMS-seglo also sagst du, dass du hast:

• [x] Soft Delete aktiviert
• [x] Aufbewahrungsfrist auf den Standardwert von 90 Tagen festgelegt
• [x] Netzwerk auf Gesamtnetzwerk eingestellt
• [x] und appgw Identität korrekt konfiguriert

und Sie erhalten immer noch diesen Fehler?

@ mark-szabo Ich habe all diese Kontrollkästchen aktiviert. Und die ARM-Vorlage wirft mir einen Fehler:

"Invalid value for the identities '/subscriptions/<sub-id>/resourceGroups/wb-all-rg-commons/providers/Microsoft.ManagedIdentity/userAssignedIdentities/wb-application-gateway-identity'. The 'UserAssignedIdentities' property keys should only be empty json objects, null or the resource exisiting property."

Die Eigenschaft ist wie folgt festgelegt:

"identity": {
    "type": "UserAssigned",
    "userAssignedIdentities": {
           "[parameters('gatewayIdentityId')]": {
                 "principalId": "[parameters('identityObjectId')]",
                 "clientId": "[parameters('identityClientId')]"
            }
     }
}

Parameter sind:

New-AzResourceGroupDeployment -Name "Gateway" `
        -ResourceGroupName "wb-devtest-core" `
        -TemplateFile './arm_templates/appgateway.azrm.json' `
        -TemplateParameterObject @{ `
            certificateSecretUrl    = "https://my-key-vault.vault.azure.net/secrets/some-name/some-id"; `
            certificateName         = "certNamel"; `
            gatewayIdentityId       = "/subscriptions/sub-id/resourceGroups/wb-all-rg-commons/providers/Microsoft.ManagedIdentity/userAssignedIdentities/wb-application-gateway-identity"; `
            identityClientId        = "id-here"; `
            identityObjectId        = "objIdHere";

BEARBEITEN:

Auch wenn ich ARM in ein eigenes SSL-Zertifikat mit Rohdaten geändert habe. Die Identitätseigenschaft löst immer noch den gleichen Fehler aus.

Irgendeine Lösung dafür?

@ mark-szabo Vielen Dank für Ihre Antwort. Ich konnte das gesamte Setup erneut mit neuen Augen durchgehen und fand einen Punkt, an dem sich meine Konfiguration unterschied: Die KeyVault-Firewall wurde auf "Privater Endpunkt und ausgewählte Netzwerke" gesetzt. aber mit "Erlauben Sie vertrauenswürdigen Microsoft-Diensten, diese Firewall zu umgehen?" auf aktiviert gesetzt.
Wenn ich "Alle Netzwerke" zuließ, konnte ich erfolgreich einen https-Listener im Portal mit einem SSL-Zertifikat von KeyVault erstellen. Es sieht also so aus, als gäbe es immer noch ein Problem mit den Netzwerkeinschränkungen.

@ CMS-seglo yup, es ist ein bekanntes Problem, das hier verfolgt wird: https://github.com/MicrosoftDocs/azure-docs/issues/48866

@kszymanski Was hast du für das 'certificateSecretUrl' eingestellt? 'some-id' in Ihrer URL muss die 'Version' des Zertifikatobjekts in KeyVault sein. Leider wird dies weder von 'az keyvault-Zertifikatsliste - Tresorname ...' noch von 'Get-AzKeyVaultSecret' oder 'Get-AzKeyVaultCertificate' in Powershell zurückgegeben, sondern im Portal angezeigt, wenn Sie sich das Zertifikat in KeyVault ansehen .

Ich hatte den gleichen irreführenden Fehler, den Sie oben erwähnt haben, weil ein "defektes" Zertifikat erstellt wurde. Sobald ich die richtige ID herausgefunden hatte, funktionierte es.

@kszymanski Was hast du für das 'certificateSecretUrl' eingestellt? 'some-id' in Ihrer URL muss die 'Version' des Zertifikatobjekts in KeyVault sein. Leider wird dies weder von 'az keyvault-Zertifikatsliste - Tresorname ...' noch von 'Get-AzKeyVaultSecret' oder 'Get-AzKeyVaultCertificate' in Powershell zurückgegeben, sondern im Portal angezeigt, wenn Sie sich das Zertifikat in KeyVault ansehen .

Ich hatte den gleichen irreführenden Fehler, den Sie oben erwähnt haben, weil ein "defektes" Zertifikat erstellt wurde. Sobald ich die richtige ID herausgefunden hatte, funktionierte es.

Es ist hier verschleiert. Ich setze eine ID vom Portal aus. Ich habe sowohl Certificate Identifier als auch Secret Identifier in beiden Fällen ohne Glück ausprobiert. Wie bereits erwähnt, ändert auch das Festlegen eines Zertifikats mit Rohdaten und Kennwort (vollständig entfernte Key Vault-Referenzen) nichts, was immer noch den gleichen Fehler darstellt. Daher denke ich, dass es eher ein Problem mit der Identitätszuweisung als mit der URL des Schlüsseldepotzertifikats sein könnte.

Ich musste schließlich das Zertifikat und das Passwort manuell hochladen, anstatt KeyVault zu verwenden, da ich den KeyVault nicht zum Laufen bringen konnte. Wenn Sie dies jedoch über das Portal tun, sobald Sie diesen Fehler erhalten, müssen Sie ein neues Anwendungsgateway erstellen, wie von einer anderen Person erwähnt. Sie können Ihr fehlerhaftes Gateway aus irgendeinem Grund nicht anpassen.

Wie Sie sehen, erstelle ich es immer wieder aus der ARM-Vorlage. Und Änderungen manuell vornehmen, nachdem es übrigens erstellt wurde. dann kann ich im portal diese identität und zertifikation problemlos zuweisen.

@ Kylehayes das ist nicht ganz richtig. Ja, Sie können es derzeit nicht aus dem Portal aus dem Status "Fehlgeschlagen" entfernen, aber Sie können dies über PowerShell oder die CLI tun.

Z.B. Löschen Sie den fehlgeschlagenen Listener, die Regel und das Zertifikat und aktualisieren Sie das GW.

$AppGw = Get-AzApplicationGateway -Name "<name>" -ResourceGroupName "<rg_name>"
Remove-AzApplicationGatewayHttpListener -ApplicationGateway $AppGw -Name "<listener_name>"
Remove-AzApplicationGatewayRequestRoutingRule -ApplicationGateway $AppGW -Name "<rule_name>"
Remove-AzApplicationGatewaySslCertificate -ApplicationGateway $AppGW -Name "<cert_name>"
Set-AzApplicationGateway -ApplicationGateway $AppGW

Ich hatte das gleiche Problem mit einem neuen KV mit einer konfigurierten Netzwerk-Firewall. Als Test, nachdem ich die Firewall ausgeschaltet hatte, wurde der Fehler in der ARM-Bereitstellung ausgelöst. Ich stimme auch zu, dass dies funktionieren muss, da mein Kunde die KV sperren möchte.

1. Es gibt immer noch ein Problem mit einer Aufbewahrungsfrist von nicht 90 Tagen. In diesem Fall lautet der Fehler "_Die Eigenschaftsschlüssel 'UserAssignedIdentities' sollten nur leere JSON-Objekte sein, null oder die vorhandene Ressource ._ " (Übrigens enthält diese Fehlermeldung einen Tippfehler.) Problemumgehung ist das Festlegen der KV-Objekteigenschaft 'softDeleteRetentionInDays' bis 90. Sie können hierfür https://resources.azure.com/ verwenden .

2. Die App GW-Verwaltungsebene verwendet einige zufällige IPs in Azure DC, um auf KV zuzugreifen. Siehe https://github.com/MicrosoftDocs/azure-docs/issues/48866. Um dieses Problem zu umgehen, können Sie die IP-Adresse aus KV-Überwachungsprotokollen (OMS oder Speicherkonto) ermitteln und zur Liste der zulässigen Elemente hinzufügen, anstatt alle Netzwerke zuzulassen. Leider gibt es keine Garantie dafür, dass die IP gleich bleibt. Außerdem müssen Sie diese IP-Adresse immer in der Liste behalten, da bei jeder Änderung der App GW-Konfiguration das gesamte Konfigurationsobjekt neu erstellt wird.

Um "kaputte" App GW vom Portal aus zu reparieren, müssen Sie:

1. Stellen Sie sicher, dass der KV-Soft-Löschzeitraum 90 Tage beträgt
2. Die KV-Firewall ist deaktiviert
3. Führen Sie eine Verwaltungsaktion im Portal aus, die die Aktualisierung des App GW-Konfigurationsobjekts auslöst

Leider müssen Sie PS weiterhin verwenden, um das Konfigurationsobjekt von Links zu Zertifikaten in der KV zu bereinigen, da Zertifizierungsobjekte in der Benutzeroberfläche des Portals nicht verfügbar sind.

Diese ganze KV / AppGW-Integrationsgeschichte musste vor der Veröffentlichung besser getestet werden.

Wir haben das gleiche Symptom festgestellt ("Die Eigenschaftsschlüssel 'UserAssignedIdentities' sollten nur leere JSON-Objekte sein, null oder die Ressource, die vorhanden ist."), Unser weicher Löschzeitraum beträgt 90 Tage und die Firewall ist geöffnet. Wir haben KV in einer "persistenten" Ressourcengruppe mit dem Anwendungsstapel in einer vorübergehenden Gruppe. Der DEV-Stack wurde vor einer Woche abgerissen und versucht, ihn wieder hochzufahren (über ARM). Der Prozess schlägt auf Application Gateway fehl. Dies bedeutet, dass wir keine Entwicklung durchführen können, bis dies wieder funktioniert.

Ich habe auch das gleiche Problem bei der Bereitstellung aus der ARM-Vorlage. Ich habe das Löschen 90 Tage lang beibehalten und die Firewall für alle Netzwerke geöffnet, aber immer noch das gleiche Problem. Es funktioniert über das Portal, aber nicht über die ARM-Vorlage.
. Die Eigenschaftsschlüssel 'UserAssignedIdentities' sollten nur leere JSON-Objekte, null oder die vorhandene Ressource sein.

Dies ist das dritte Mal, dass dasselbe Appgateway nach La-La-Land fährt. Kann nicht stoppen und / oder aktualisieren:
{
"Error": {
"code": "MissingIdentityIds",
"message": "Die Identitäts-IDs dürfen für den Identitätstyp 'UserAssigned' nicht null oder leer sein."
}}
}}

Um ehrlich zu sein. Ich habe es aufgegeben, weil es instabil ist.

Am Do, 23. April 2020 um 15:46 Uhr schrieb pererap01 [email protected] :

Dies ist das dritte Mal, dass dasselbe Appgateway nach La-La-Land fährt. Kann nicht aufhören und
oder Update:
{
"Error": {
"code": "MissingIdentityIds",
"message": "Die Identitäts-IDs dürfen für 'UserAssigned' nicht null oder leer sein.
Identitätstyp."
}}
}}

- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/MicrosoftDocs/azure-docs/issues/33157#issuecomment-618624144 ,
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ABD32Z2KPUY7KBFNPTCVMA3ROCLJ3ANCNFSM4HXFRP4A
.

wir mussten einen anderen aufstehen und diesen benutzen, weil der ursprüngliche schuppig ist! Ich habe ein Ticket mit MS zu diesem Problem. Mal sehen, ob es dieses Mal behoben wird.

@ SubhashVasarapu-MSFT Gibt es eine Möglichkeit, potenzielle Blocker aufzulisten, warum solche Inkonsistenzen auftreten? Kann die Grundursache / Einschränkung sein.

Es wäre sogar noch besser, wenn wir den aktuellen Status mit dem Fix erhalten würden.

Wie andere in diesem Thread habe auch ich einen Fehler erhalten:

Failed to save configuration changes to application gateway <REDACTED>. Error: Either Data or KeyVaultSecretId must be specified for Certificate <REDACTED>...

In der Zugriffsrichtlinie des Schlüsseldepots habe ich alle Schlüssel-, Geheim- und Zertifikatberechtigungen für die von Azure Gateway verwendete verwaltete Identität aktiviert. Ich bin mir sicher, dass dies übertrieben ist, aber nachdem ich eine Mischung aus anderen Berechtigungen ausprobiert hatte, war ich frustriert und habe einfach alles aktiviert. Danach ging der Fehler weg.

PS e2e TLS bei Verwendung eines von der Cloud bereitgestellten Zertifikats ist ein sehr häufiges Szenario. Als Neuling bei Azure bin ich sehr enttäuscht, dass dies noch keine ausgefeilte Erfahrung ist.

Ich habe versucht, Geheimnisse und Zertifikate von KeyVault über Application Gateway auf meinen Cluster abzurufen, wodurch meine Anwendung fehlschlägt, da sie sich nicht bei KV authentifizieren kann und dies zu einem fehlerhaften Gateway-Fehler führt.

Verbindungs-ID "0HM0BI3H5TUJP", Anforderungs-ID "0HM0BI3H5 TUJP: 00000001 ": Eine nicht behandelte Ausnahme wurde von der Anwendung ausgelöst.
Verbindungs-ID "0HM0BI3H5TUNQ", Anforderungs-ID "0HM0BI3H5 TUNQ: 00000002 ": Eine nicht behandelte Ausnahme wurde von der Anwendung ausgelöst.

Ich erhalte diese Fehler in meinen Protokollen des Pods, der versucht, das Geheimnis zu erlangen.

In My KeyVault ist das Soft-Löschen aktiviert, wobei standardmäßig 90 Tage als Aufbewahrungszeitraum und das Netzwerk für alle Netzwerke festgelegt sind. Meine App Gateway-Identität ist auch im Tresor korrekt konfiguriert. Weiß jemand, wo ich falsch liege?

Ich habe mit einem Ingenieur von MS gearbeitet
Dies ist die Zusammenfassung dessen, was ich herausgefunden habe

1. Löschen Sie alle Zertifikate, die Appgateway-Listenern zugeordnet sind. Grundsätzlich alle Appgateway installierten Zertifikate entfernen
   zu überprüfen: PS
   az Netzwerkanwendung-Gateway SSL-Zertifikat-Liste -g (Ressourcengruppe) - Gateway-Name (Gateway-Name)
   wenn folgendes auftaucht
   "keyVaultSecretId": null,
   Das Zertifikat wird auf dem AppGateway installiert und die meisten werden getrennt
2. Sobald das Zertifikat im Appgateway fehlt, ordnen Sie das Zertifikat aus dem Schlüsseldepot zu und es sollte funktionieren

Ich habe mit einem Ingenieur von MS gearbeitet
Dies ist die Zusammenfassung dessen, was ich herausgefunden habe

1. Löschen Sie alle Zertifikate, die Appgateway-Listenern zugeordnet sind. Grundsätzlich alle Appgateway installierten Zertifikate entfernen
   zu überprüfen: PS
   az Netzwerkanwendung-Gateway SSL-Zertifikat-Liste -g (Ressourcengruppe) - Gateway-Name (Gateway-Name)
   wenn folgendes auftaucht
   "keyVaultSecretId": null,
   Das Zertifikat wird auf dem AppGateway installiert und die meisten werden getrennt
2. Sobald das Zertifikat im Appgateway fehlt, ordnen Sie das Zertifikat aus dem Schlüsseldepot zu und es sollte funktionieren

Dies ist in meinem Szenario nicht der Fall, da die gesamte Ressourcengruppe, einschließlich des Anwendungsgateways, zerstört und neu erstellt wurde. Dieses Problem besteht jedoch weiterhin.

Dann gehe ich davon aus, dass es ein Problem mit dem Schlüsseldepot gibt und wie es mit dem Apgateway kommuniziert ...
Haben Sie sich den Ressourcenmanager angesehen und eine Get-Anfrage ausgeführt? Möglicherweise erhalten Sie eine bessere Fehlerbehandlung und / oder führen sie im Debug-Modus aus

Ich berühre den Key Vault selbst im Moment nicht, damit der MS-Support ihn in seinem aktuellen Zustand sehen kann.

Woher wird die Fehlermeldung generiert? Ist es Version 2 mit aktiviertem WAF?

Ja, V2 WAF. Der Fehler kommt von ARM. Wird von einem von ADO gehosteten Windows-Agenten mithilfe der AZ-CLI ausgeführt

az group deployment create --debug --mode Complete

Hinweis: Die ARM-Vorlage enthält den gesamten Stapel, VNET, VMs, APG usw. Mit Key Vault und anderen bleibt in einer separaten Ressourcengruppe bestehen.

Ah ok….

Von: Continuous Delivery Automation Framework [email protected]
Gesendet: Montag, 8. Juni 2020, 13:01 Uhr
An: MicrosoftDocs / azure -docs
CC: Perera, Priyantha, Arvato SCS [email protected] ; Kommentar [email protected]
Betreff: Betreff: [MicrosoftDocs / azure-docs] Anwendungsgateway: Die Integration mit Key Vault funktioniert nicht (# 33157)

Ja, V2 WAF. Der Fehler kommt von ARM. Wird von einem von ADO gehosteten Windows-Agenten mithilfe der AZ-CLI ausgeführt

Az-Gruppenbereitstellung create --debug --mode Complete

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und sehen Sie sie auf GitHub https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F33157%23issuecomment-640855594&data = 02% 7C01% 7C% 7C742cf0b3589c42d4021508d80be6b732% 7C1ca8bd943c974fc68955bad266b43f0b% 7C0% 7C0% 7C637272432826294946 & sdata = qdtJwYk5QV8evtt8Bp% 2B1% 2Bn7lkz5ebEG% 2BCMAfdQVmSS4% 3D & reserviert = 0 oder abmelden https://eur02.safelinks.protection.outlook.com/?url=https% 3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-auth% 2FAF2ZC6CPCTZUSOKGAT7F523RVU7RBANCNFSM4HXFRP4A & data = 02% 7C01% 7C% 7C742cf0b3589c42d4021508d80be6b732% 7C1ca8bd943c974fc68955bad266b43f0b% 7C0 7C0%% 7C637272432826304943 & SDATA = TgPtoOi5neDLlb% 2B0hk% 2BEULQyZSUFV8fy4deb9RgUsKk% 3D & reserviert = 0 .

@ pererap01
Sie verwenden "--mode Complete" - dies entfernt möglicherweise "versteckte" Ressourcen, die nicht in der Vorlage definiert sind.
Außerdem muss der Benutzer- / Dienstprinzipal, der die Bereitstellung ausführt, in der Lage sein, MSI zu lesen, die WAF für den Zugriff auf KV verwendet, wenn diese MSI nicht Teil der Bereitstellung ist.

@gaikovoi , ich denke, diese Referenz war für mich. Wir verwenden denselben ARM und dieselbe Ausführung in drei Umgebungen, und alle haben einwandfrei funktioniert. Die DEV-Umgebung wurde jeden Freitag abgerissen und jeden Montag neu erstellt, sodass das Team eine neue Umgebung hatte, an der es die ganze Woche über arbeiten konnte (wir haben manchmal einen Ad-hoc-Abriss / Standup durchgeführt, wenn einer der DEV ein Chaos angerichtet hat). Eine Woche kam es einfach nicht, obwohl sich kein anderer Aspekt des Einsatzes geändert hatte.

@cdaf gab es heute ein ARM-Problem
Behoben: RCA - Azure Resource Manager - Fehler beim Erstellen oder Löschen von Ressourcen

Manchmal schlagen ARM-Bereitstellungen jedoch ohne triftigen Grund fehl. Dies wird normalerweise durch erneutes Ausführen der AzDO-Pipeline behoben.

@gaikovoi , ja, ARM kann sehr temperamentvoll sein (insbesondere wenn Sie versuchen, APIM über ARM bereitzustellen). Dies ist hier jedoch nicht der Fall. Es wurde fast 30 Mal wiederholt (von verschiedenen Personen, die versuchen, es zu diagnostizieren).

Hallo zusammen. Ich habe ein Konto erstellt, um darauf zu antworten, weil es so frustrierend war. Für alle, die mich mögen, den KeyVault nicht auf Alle Netzwerke einstellen können oder wollen ... Ich habe eine Problemumgehung gefunden. Wenn Sie zum Ressourcen-Explorer gehen und Folgendes löschen, sollte Ihr App Gateway wieder glücklich sein.

1. Löschen Sie das Identitätsobjekt
2. Löschen Sie das Zertifikat, das den Fehler verursacht hat, unter sslCertificates
3. Löschen Sie alle Vorkommen Ihres ausgefallenen Listeners
4. PUT Ihre Änderungen

Dies führte sofort zu einem Update meines App Gateways und brachte es in einen fehlerfreien Bereitstellungszustand. Zugegeben, ich war zu ausgebrannt / frustriert von dem Prozess, um zu versuchen, die KeyVault-Integration durchzuführen, also habe ich das Zertifikat einfach direkt auf das App Gateway hochgeladen und es hat gut funktioniert. Die KeyVault-Integration muss wirklich von Microsoft behoben werden ...

Ich hoffe, das hilft jemandem.

Prost.

Nur um all das zu wiederholen. Dieses Problem ist in Azure definitiv immer noch vorhanden und beeindruckt mich ehrlich.

Nach dem Hinzufügen einer verwalteten Identität zum Verwalten von Berechtigungen für ein von AZURE GEKAUFTES Platzhalterzertifikat und dem Befolgen aller dokumentierten Schritte zum Hinzufügen dieses Zertifikats zum Gateway tritt weiterhin ein Fehler auf, der darauf hinweist, dass die Identität keinen Zugriff auf den Tresor hat. Überprüfen Sie sowohl den Tresor als auch das Zertifikat, um sicherzustellen, dass es tatsächlich Zugriff hat, was auch der Fall ist. Entscheiden Sie sich dafür, die Berechtigungen vom einfachen Lesezugriff auf den Eigentümer zu übertragen, um festzustellen, ob das Problem dadurch behoben wird, und geben Sie einen Fehler in Bezug auf Sperren des Platzhalterzertifikats an.

Daher kann ich das Zertifikat nicht nur nicht über die Key Vault-Methode hinzufügen, sondern jetzt auch versuchen, Elemente zu bereinigen oder die Berechtigungen der Identität zu ändern, nachdem ich mehrere Konfigurationen versucht habe. Ich kann die Identität nicht einmal aus Azure entfernen, ohne die Sperre "Löschen" zu entfernen das Wildcard-Zertifikat, das der Client gekauft hat. Ehrlich gesagt besteht die einfachste Methode, die ich hier gefunden habe, darin, das Zertifikat zu exportieren, der PFX-Datei ein Kennwort hinzuzufügen und es schließlich während der Erstellung des Gateways erneut hochzuladen. Dies alles wurde über die GUI durchgeführt, in der Hoffnung, eine korrekte ARM-Vorlage zu erstellen, die während der Bereitstellung über Terraform verwendet werden kann. Immer noch kaputt.

Dies scheint eine ziemlich grundlegende Sache zu sein, die Azure gerne ignoriert.

Was für ein absoluter Albtraum - ich kann nicht glauben, dass über ein Jahr Feedback und Probleme und dies immer noch nicht behoben ist. Unser Schlüsseldepot war für alle Netzwerke offen, weiche Löschvorgänge wurden aktiviert und auf 90 Tage eingestellt, und der erste Versuch, die beiden zu verbinden, führte zu einer Unterbrechung des Gateways.

Dies ist wirklich ein stark kaputtes Produkt. 😠

Hier gilt das gleiche. Wie kann dies eine offene Ausgabe für 1 + Jahr sein? Es ist schrecklich, App Gateway WAF v2 zu verwenden.
Wann wird das behoben?

Immer noch eine Sache! In meinem Fall scheint es sich um die Keyvault-Netzwerkintegration zu handeln. Das Portal prüft dies definitiv nicht und schlägt mit einem zufälligen Eigenschaftsschlüsselfehler fehl (kein verbotener Fehler, wie Sie es erwarten würden). Kann jemand bestätigen, ob die Aktivierung von VNET Service-Endpunkten für Microsoft.Keyvault im Gateway-Subnetz diese Integration mit aktivierter KeyVault FW ermöglichen würde?

Es wurde versucht, ein bereits vorhandenes Zertifikat, das auf GW hochgeladen wurde, zu "erneuern oder zu bearbeiten". + PAAS KV mit aktivierter FW + aktivierter IPWhitelist verwenden

Invalid value for the identities '/subscriptions/{sub-id}/resourcegroups/{rg-name}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{uami-name}'. The 'UserAssignedIdentities' property keys should only be empty json objects, null or the resource exisiting property.

(auf demselben Listener oben) Es wurde versucht, ein bereits vorhandenes, auf GW + hochgeladenes Zertifikat zu "erneuern oder zu bearbeiten". Verwenden Sie PAAS KV mit FW DISABLED

• ERFOLG

Auf einem anderen Hörer
Es wurde versucht, ein bereits vorhandenes Zertifikat, das auf GW + hochgeladen wurde, zu "erneuern oder zu bearbeiten". Verwenden Sie PAAS KV mit FW DISABLED

• ERFOLG

Hallo zusammen. Ich habe ein Konto erstellt, um darauf zu antworten, weil es so frustrierend war. Für alle, die mich mögen, den KeyVault nicht auf Alle Netzwerke einstellen können oder wollen ... Ich habe eine Problemumgehung gefunden. Wenn Sie zum Ressourcen-Explorer gehen und Folgendes löschen, sollte Ihr App Gateway wieder glücklich sein.

1. Löschen Sie das Identitätsobjekt
2. Löschen Sie das Zertifikat, das den Fehler verursacht hat, unter sslCertificates
3. Löschen Sie alle Vorkommen Ihres ausgefallenen Listeners
4. PUT Ihre Änderungen

Dies führte sofort zu einem Update meines App Gateways und brachte es in einen fehlerfreien Bereitstellungszustand. Zugegeben, ich war zu ausgebrannt / frustriert von dem Prozess, um zu versuchen, die KeyVault-Integration durchzuführen, also habe ich das Zertifikat einfach direkt auf das App Gateway hochgeladen und es hat gut funktioniert. Die KeyVault-Integration muss wirklich von Microsoft behoben werden ...

Ich hoffe, das hilft jemandem.

Prost.

In der gleichen Situation!. Ich werde das Zertifikat direkt hinzufügen und KeyVault nicht verwenden, da ich Key Vault auch auf Subnetze beschränken muss
Prost, Rui

Stoßen! Dies ist auch bei Verwendung von Terraform immer noch ein Problem. Wenn die Firewall auf dem KV aktiviert ist, schlägt die AppGW-Bereitstellung fehl.

Versuchte schon viele Dinge:

• Auf dem KV eingeschaltet
  
  
  
  • Azure Resource Manager für die Vorlagenbereitstellung
  
  
  • Erlauben Sie vertrauenswürdigen Microsoft-Diensten, diese Firewall zu umgehen?
  
  
• Service-Endpunkt im AppGW-Subnetz und Hinzufügen des Netzwerks zur KV-FW
• Hinzufügen der publicIP der AppGW zur KV FW

... Keiner von ihnen funktioniert. Die einzige Lösung besteht darin, die Firewall auf dem Schlüsseldepot zu deaktivieren.

Auch mit diesem Problem. Bitte untersuchen Sie!

Immer noch eine Sache! In meinem Fall scheint es sich um die Keyvault-Netzwerkintegration zu handeln. Das Portal prüft dies definitiv nicht und schlägt mit einem zufälligen Eigenschaftsschlüsselfehler fehl (kein verbotener Fehler, wie Sie es erwarten würden). Kann jemand bestätigen, ob die Aktivierung von VNET Service-Endpunkten für Microsoft.Keyvault im Gateway-Subnetz diese Integration mit aktivierter KeyVault FW ermöglichen würde?

Es wurde versucht, ein bereits vorhandenes Zertifikat, das auf GW hochgeladen wurde, zu "erneuern oder zu bearbeiten". + PAAS KV mit aktivierter FW + aktivierter IPWhitelist verwenden

Invalid value for the identities '/subscriptions/{sub-id}/resourcegroups/{rg-name}/providers/Microsoft.ManagedIdentity/userAssignedIdentities/{uami-name}'. The 'UserAssignedIdentities' property keys should only be empty json objects, null or the resource exisiting property.

(auf demselben Listener oben) Es wurde versucht, ein bereits vorhandenes, auf GW + hochgeladenes Zertifikat zu "erneuern oder zu bearbeiten". Verwenden Sie PAAS KV mit FW DISABLED

* SUCCESS

Auf einem anderen Hörer
Es wurde versucht, ein bereits vorhandenes Zertifikat, das auf GW + hochgeladen wurde, zu "erneuern oder zu bearbeiten". Verwenden Sie PAAS KV mit FW DISABLED

* SUCCESS

Scheint bei mir nicht zu funktionieren. Ich habe auch viele Kombinationen ausprobiert. Die einzige Lösung bestand darin, auch meine KV-Firewall vollständig zu deaktivieren.

Dies scheint auch bei mir der Fall zu sein; Dies funktioniert nur, wenn die Keyvault-Firewall vollständig deaktiviert wird.

Das gleiche Problem auch für mich ... wie kann das noch nicht gelöst werden?

Ich verstehe nicht - wir sind auch nur darauf gestoßen. Was ist die richtige Konfiguration hier?

Nachdem ich ein Ticket mit Azure-Support geöffnet habe, habe ich die offizielle Antwort erhalten:
"Wie in unserem Gespräch erläutert, unterstützt Application Gateway derzeit die Integration mit Key Vault nicht, wenn Key Vault nicht für den Zugriff auf" Öffentliche Endpunkte (alle Netzwerke) "konfiguriert ist.
Wir arbeiten derzeit intern mit den erforderlichen Teams zusammen, um alle Netzwerkkonfigurationen auf Key Vault im Hinblick auf die Integration in Application Gateway zu unterstützen.

Die offizielle Dokumentation dazu wird in Kürze veröffentlicht. "

@lonevvolf Sie können den Keyvault für alle Netzwerke öffnen, das SSL-Zertifikat mit einer verwalteten Identität an Ihre Listener binden und dann den Keyvault durch eine Firewall sichern (oder ihn an ein vnet sperren). Appgw funktioniert weiterhin mit dem _cached_ ssl-Zertifikat, aber dann, wenn Wenn Sie das Zertifikat im Keyvault ersetzen, bevor es abläuft, kann appgw keinen Rollover auf das erneuerte Zertifikat durchführen. Also muss man vorsichtig sein. Aber ja, es ist kaputt.

@Microsoft Können wir bitte ein Update zu diesem Problem erhalten? Es ist immer noch nicht gelöst und zwingt Ihre Azure-Unternehmenskunden, Key Vault für alle Netzwerke verfügbar zu machen. Es ist über ein Jahr her, seit dies gemeldet wurde, viel Zeit, um es auf die Roadmap zu setzen.

Wie in unserem Gespräch erläutert, unterstützt Application Gateway derzeit die Integration in Key Vault nicht, wenn Key Vault nicht für den Zugriff auf "Öffentliche Endpunkte (alle Netzwerke)" konfiguriert ist.
Wir arbeiten derzeit intern mit den erforderlichen Teams zusammen, um alle Netzwerkkonfigurationen auf Key Vault im Hinblick auf die Integration in Application Gateway zu unterstützen.

Auch diese Einschränkung muss irgendwo dokumentiert werden. Können wir diese Aussage irgendwo in die MSFT-Dokumentation aufnehmen?

Dieses Dokument sollte beispielsweise die folgende Anweisung enthalten: https://docs.microsoft.com/en-us/azure/application-gateway/key-vault-certs

@oising wie erwähnt "Sie können den Keyvault für alle Netzwerke öffnen, das SSL-Zertifikat mit einer verwalteten Identität an Ihre Listener binden und dann den Keyvault durch eine Firewall sichern (oder ihn an ein vnet sperren). Appgw arbeitet weiterhin mit dem zwischengespeicherten SSL-Zertifikat . "

Unterstützt az cli diese Funktion? Können wir mit az cli einen http-Listener im App-Gateway mit ssl cert erstellen (aus wichtigen Tresorzertifikaten ziehen)? Wenn ja, geben Sie bitte den Befehl az cli an. Danke im Voraus.

@lonevvolf Sie können den Keyvault für alle Netzwerke öffnen, das SSL-Zertifikat mit einer verwalteten Identität an Ihre Listener binden und dann den Keyvault durch eine Firewall sichern (oder ihn an ein vnet sperren). Appgw funktioniert weiterhin mit dem _cached_ ssl-Zertifikat, aber dann, wenn Wenn Sie das Zertifikat im Keyvault ersetzen, bevor es abläuft, kann appgw keinen Rollover auf das erneuerte Zertifikat durchführen. Also muss man vorsichtig sein. Aber ja, es ist kaputt.

Hmm. Was ist, wenn Sie die Key Vault-Firewall vor der Installation des erneuerten Zertifikats ausgeschaltet und anschließend wieder eingeschaltet haben? Würde die AGW die Änderung sehen und das neue Zertifikat schnell genug abrufen, während die Firewall heruntergefahren ist? Ich arbeite derzeit an einer Azure-Funktion mit einem Timer, um die Erneuerung des Zertifikats in Key Vault mithilfe von certbot / Let's Encrypt durchzuführen. Ich sollte in der Lage sein, einige az -Befehle zu schreiben, um die Key Vault-Firewall zu deaktivieren und wieder zu aktivieren, während das Zertifikat in Key Vault aktualisiert wird.

Es ist albern, dass all dies überhaupt notwendig ist. : /

Weiß jemand, ob es Pläne gibt, FW auf dem Schlüsseldepot zu unterstützen -> "Privater Endpunkt und ausgewählte Netzwerke"?

Hinzufügen eines weiteren Kommentars, um die Gefühle anderer wiederzugeben. Dieses Problem ist sehr frustrierend, da die Bereitstellung aller Netzwerke für Key Vault für viele Unternehmen häufig keine Lösung darstellt. Ich stoße mit Terraform darauf und muss es derzeit umgehen. Ein Fix von @microsoft wäre fantastisch.

Das gleiche gilt für mich, wir können kein offenes Internet-KV oder AppGW haben und können die Funktion nicht so oft nutzen, wie wir möchten. : /

Habe heute das gleiche Problem. :(

Eine weitere praktikable Option für Leute, die sich über den Kampf mit AppGW ärgern, ist die Verwendung von Azure Frontdoor (es handelt sich im Grunde genommen um eine abgespeckte AppGW), die jedoch nur in öffentlichen Netzwerken (keine VNets) funktioniert. Sie kann öffentlich zugängliche SSL-Zertifikate automatisch generieren.

Wir arbeiten aktiv daran, AppGW die Arbeit mit KeyVaults zu ermöglichen, die nur private Endpunkte zulassen und den Netzwerkzugriff auswählen. Gemäß dem Vorschlag von Dokumente so aktualisiert, dass sie im Abschnitt "Funktionsweise der Integration" einen wichtigen Hinweis zu dieser Einschränkung enthalten. Wir werden diesen Thread sowie die Dokumente aktualisieren, sobald AppGW alle KeyVault-Konfigurationen unterstützen kann.

@ Skinlayers , die funktionieren könnten - werden es nicht wissen, bis Sie es versuchen!

Ich konnte dies mit den folgenden Schritten beheben:

• Entfernen Sie das vorhandene ssl-cert-Profil mit az network application-gateway ssl-cert remove
• Deaktivieren Sie die Firewall vorübergehend und erlauben Sie den Zugriff von allen Netzwerken
• Binden Sie das Zertifikat erneut aus dem Azure Key Vault (ich habe zweimal überprüft, ob alle Dienstidentitätsberechtigungen in Ordnung sind).
• Deaktivieren Sie den Zugriff aus allen Netzwerken erneut

Alles funktioniert in Ordnung

HINWEIS: Die oben beschriebene Problemumgehung wird nicht empfohlen. Microsoft hat uns darauf hingewiesen, dass zukünftige automatische Skalierungsvorgänge auf dem Application Gateway fehlschlagen werden , da diese Methode verwendet und die Firewall erneut aktiviert wurde. Dies erfordert wirklich eine vollständige Korrektur von Microsoft.