@DanijelMalik 、フィードバックをありがとうございます。 このクエリを調査しており、できるだけ早く更新します。

@DanijelMalik 、このエラーのPowerShell出力を提供してください。 これに似ている、
注：サブスクリプションIDやシークレットなどの機密領域は必ずマスクしてください。
{{
「ステータス」：「失敗」、
「エラー」：{
"コード"： "ApplicationGatewayKeyVaultSecretException"、
"メッセージ"： "アプリケーションゲートウェイに関連付けられたKeyVaultシークレットへのアクセスと検証中に問題が発生しました '/subscriptions/XXXXXXXXXXXXXXXX/resourceGroups/XXXXXXXXXXXX/providers/Microsoft.Network/applicationGateways/applicationGatewayV2'。以下の詳細を参照してください："、
「詳細」：[
{{
"コード"： "ApplicationGatewayKeyVaultSecretAccessDenied"、
"メッセージ"： "アプリケーションゲートウェイのKeyVaultシークレット 'XXXXXXXXXXXXXXXXX'のアクセスが拒否されました '/subscriptions/XXXXXXXXXXX/resourceGroups/XXXXXXXXXXXXX/providers/Microsoft.Network/applicationGateways/applicationGatewayV2'。アプリケーションゲートウェイに割り当てられたIDがKeyVaultにアクセスできることを確認してください秘密に関連付けられています。」
}
]
}
}

@DanijelMalik 、前の応答を表示する時間があったかどうかを確認するだけです。

@DanijelMalik 、あなたからの返信がないので、このスレッドを閉じます。 この件に関してさらに質問がある場合は、返信にタグを付けてください。 喜んで問題を再開し、議論を続けます。

ここで同じ問題。

私の場合、これはキーボールトでソフト削除を有効にすることで解決されました。

この要件が文書化されていないという既存の問題があります：＃34382

こんにちは、私は同じ問題を経験しています。 問題のように思われるのは、keyvaultはappGwサブネットからのアクセスを許可しているにもかかわらず（keyvault構成のファイアウォールと仮想ネットワーク設定ブレードを介して）です。 また、appGwサブネットが-GatewayIpConfigurations引数を介してNew-AzApplicationGatewayに入力されているため、appGwはキーボールトにアクセスできないようです（IDにはキーボールトアクセスポリシーのアクセス権もあります）。

「すべてのネットワーク」からキーボールトへのアクセスを許可すると、正常に機能しているようです。

おそらく、appGw作成プロセスで、appGwがサブネットで構成される前にキーボールトにアクセスし、キーボールトがサブネット以外の場所からのこのアクセスを確認しますか？

PowerShellスクリプトをローカルで実行していますが、IPはキーボールトにもアクセスできるため、問題はありません。

同じ問題が発生します

@ SubhashVasarapu-MSFT

同じ問題があります。 Azure CLI2.0.76を使用しています。 私のアプリケーションゲートウェイとキーボールトは、同じサブスクリプションの異なるリソースグループにあります。 キーボールトではソフト削除が有効になっており、すべてのネットワークからアクセスでき、アプリケーションゲートウェイに割り当てられたユーザーに割り当てられたIDのアクセスポリシーがあり、シークレットの取得権限があります。

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

結果は（省略形）

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.

Azure PortalでアプリケーションゲートウェイHTTPリスナーを編集し、そこでキーボールトからSSL証明書を取得しようとすると、次のエラーが発生します。

構成変更をアプリケーションゲートウェイ「XXX」に保存できませんでした。 エラー：ID'XXX / providers / Microsoft.ManagedIdentity / userAssignedIdentities / XXX 'の値が無効です。 'UserAssignedIdentities'プロパティキーは、空のjsonオブジェクト、null、またはリソースが存在するプロパティのみである必要があります。

こんにちは、私は同じ問題を経験しています。 問題のように思われるのは、keyvaultはappGwサブネットからのアクセスを許可しているにもかかわらず（keyvault構成のファイアウォールと仮想ネットワーク設定ブレードを介して）です。 また、appGwサブネットが-GatewayIpConfigurations引数を介してNew-AzApplicationGatewayに入力されているため、appGwはキーボールトにアクセスできないようです（IDにはキーボールトアクセスポリシーのアクセス権もあります）。

「すべてのネットワーク」からキーボールトへのアクセスを許可すると、正常に機能しているようです。

おそらく、appGw作成プロセスで、appGwがサブネットで構成される前にキーボールトにアクセスし、キーボールトがサブネット以外の場所からのこのアクセスを確認しますか？

PowerShellスクリプトをローカルで実行していますが、IPはキーボールトにもアクセスできるため、問題はありません。

これは私にとってもうまくいきました。 失敗から成功への変更は、すべてのネットワークを許可することだけでした

Azure PortalでアプリケーションゲートウェイHTTPリスナーを編集し、そこでキーボールトからSSL証明書を取得しようとすると、次のエラーが発生します。

構成変更をアプリケーションゲートウェイ「XXX」に保存できませんでした。 エラー：ID'XXX / providers / Microsoft.ManagedIdentity / userAssignedIdentities / XXX 'の値が無効です。 'UserAssignedIdentities'プロパティキーは、空のjsonオブジェクト、null、またはリソースが存在するプロパティのみである必要があります。

@wolfganggalloこれとまったく同じエラーが発生します。 私の紺碧のポータルもエラー状態でスタックしているようで、変更を加えることができません。 これを修正できましたか？

Att：@ SubhashVasarapu-MSFT-再度開いてください。

同じ問題が発生します：「_ 'UserAssignedIdentities'プロパティキーは、空のjsonオブジェクト、null、またはリソースが存在するプロパティのみである必要があります_」、および別のリソースグループとvnetの--keyvault。私の場合はvnetピアリングされていないため、実行時にAPIMインスタンスとkeyvaultの間にルートはありませんが、Azure Portal UIは、使用可能なキーボールトを一覧表示し、リスナーにリンクできるようにします。一時的なvnetピアリングで問題が解決するかどうかを確認し、リスナーを削除できるようにします。その結果、現在Appgwが壊れています。

更新はい、それが問題です。 Azure Portalには、実行時に実際には使用できない主要なボールトが表示されます。リスナーの設定を保存すると、Appgwが破損します。 簡単な解決策は、キーボールトに移動し、一時的に「すべてのネットワーク/インターネット」に開いてから、リスナーを再保存することです。 次に行うことはあなた次第です-証明書をローカルキーボールトにコピーするか、vnetピアリングを追加するか、不足しているサブネットを追加します。 最終的に、ポータルはappgwとkyvault間のネットワークアクセシビリティを検証する必要があります。 バグ。

2回目の更新明確にするために：これはポータルUIを完全に破壊します。 AppGwはポータル上で修正できません。 後続の保存は失敗します。

ポータルUIでもこのエラーが発生しました。 ソフト削除が有効になっています。 すべてのネットワークの回避策を許可すると、うまくいきました。

ホワイトリストを使用できることはセキュリティに優れているため、再度開いてください。

@ SubhashVasarapu-MSFT再度開いてください。 私たちは同様の同じ問題に取り組んでいます。 ポータルUIは完全に壊れています。

すべての操作は次のメッセージで失敗します。
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 AppGwを再び機能させるには、「すべてのネットワークを許可する」を設定するだけで済みましたか？ 同じ症状で問題が発生しましたが、同じサブネットにKeyVaultがあり、根本原因が異なる可能性があります。

UI、PowerShell、CLI、またはリソースエクスプローラーを使用して何もできません。

@PgInsight @oising AppGwを再び機能させるには、「すべてのネットワークを許可する」を設定するだけで済みましたか？ 同じ症状で問題が発生しましたが、同じサブネットにKeyVaultがあり、根本原因が異なる可能性があります。

UI、PowerShell、CLI、またはリソースエクスプローラーを使用して何もできません。

KeyVaultですべてのネットワークを許可に設定し、PowerShellコマンドを使用してKeyVaultにソフト削除フラグを設定する必要もありました。

($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

私も同じ問題を抱えていました。 ただし、PowerShellを使用してKey Vault証明書を削除することで問題を解決できましたが、エクスプローラーを使用したリソースエクスプローラーでは、次のエラーが表示されませんでした。
{{
「エラー」：{
"コード"： "MissingIdentityIds"、
"メッセージ"： "'UserAssigned'IDタイプのIDIDはnullまたは空であってはなりません。"
}

}

以下のサンプルスクリプトを使用して証明書とリスナーを削除すると、アプリゲートウェイは動作状態に戻りました

アプリgwからリスナーと証明書を削除します

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

変更内容を保存

set-azapplicationgateway -ApplicationGateway $ AppGW

アプリゲートウェイが失敗状態になっていないときに、キーボールトのアクセスポリシーを確認したところ、アプリgwのIDが「アプリケーション」ではない別のカテゴリにあることがわかりました。 これが問題の原因だったと思います。
キーボールト設定からアクセスポリシーにIDを再度追加すると、「アプリケーション」として表示できるようになりました。 これで問題が解決し、キーボールトから証明書付きのリスナーを問題なく追加できました。

@ SubhashVasarapu-MSFTこれを再度開く必要があります。 App Gatewayが、このような無効化/破損状態になることはありません。同じ問題が再び発生しました。 これをどのようにエスカレーションできますか？ これはドキュメントの問題ではありません。 これは製品の品​​質の問題です。

要約する：

リモートキーボールトでSSL証明書を使用するようにリスナーを構成する場合、ポータルUIを使用すると、ネットワークの制限のために実行時にappgwで使用できないキーボールトを使用してリスナーを構成できます（インターネットに開かれていない、選択したサブネットのみ）。 これを行うと、AppGatewayポータルインターフェイスはすべてのリスナーに対して壊れます。

私はこれをそれぞれのチームに転送します。

これの状況はどうですか？

PGでこのエラーの原因の1つが見つかりました。 KeyVaultの保持期間がデフォルトの90日とは異なる設定になっている場合、ソフト削除が有効になっていて、すべてのネットワークがアクセシビリティとして設定されていても、AppGWはこのエラーメッセージをスローしていました。 このバグを修正するために、現在アップデートが公開されています。

いつ展開されますか？ 私もこの問題に遭遇しましたが、一度遭遇するとポータルから構成または変更を加えることができないというのは本当に大きな問題です。

今日これを打つだけです。 ソフト削除の保持を30日に設定し、変更できないことがわかった後、このスレッドが見つかりました。 この修正を公開したいと思います。

デフォルトの保存期間が90日であっても、まったく同じ問題
Azure CLI、Powershell、TerraForm、Portalのいずれを実行していても、「ApplicationGatewayに関連付けられたKeyVaultシークレットへのアクセスと検証中に問題が発生しました...」という同じエラーが常に発生します。

IDとアクセスポリシーをトリプルチェックしました。場所「西ヨーロッパ」の同じリソースグループ内のすべてのリソース

@ CMS-segloなので、次のようになります。

• [x]ソフト削除が有効
• [x]保持期間をデフォルトの90日に設定
• [x]ネットワークを全ネットワークに設定
• [x]とappgwIDが正しく構成されている

それでもこのエラーが発生しますか？

@ mark-szaboすべてのチェックボックスをオンにしました。 そして、ARMテンプレートは私にエラーを投げています：

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

プロパティは次のように設定されます。

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

パラメータは次のとおりです。

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";

編集：

ARMを生データを含む独自のSSL証明書に変更した場合でも。 Identityプロパティは引き続き同じエラーをスローします。

それに対する解決策はありますか？

@ mark-szabo返信ありがとうございます。新しい目でセットアップ全体をもう一度確認し、構成が異なる1つのポイントを見つけました。KeyVaultファイアウォールが「プライベートエンドポイントと選択したネットワーク」に設定されていました。しかし、「信頼できるMicrosoftサービスがこのファイアウォールをバイパスすることを許可しますか？」 有効に設定します。
「すべてのネットワーク」を許可すると、KeyVaultからのSSL証明書を使用してポータルにhttpsリスナーを正常に作成できました。 したがって、ネットワークの制限にはまだ問題があるようです。

@ CMS-segloうん、これは既知の問題であり、ここで追跡されます： https ：

@kszymanski 「certificateSecretUrl」に何を設定しましたか？ URLの「some-id」は、KeyVaultの証明書オブジェクトの「バージョン」である必要があります。 残念ながら、これは「azkeyvault証明書リスト--vault-name ...」によっても、Powershellの「Get-AzKeyVaultSecret」または「Get-AzKeyVaultCertificate」によっても返されませんが、KeyVaultで証明書を見るとポータルに表示されます。

「壊れた」証明書が作成されたため、上記と同じ誤解を招くエラーが発生しました。 正しいIDを見つけたら、それは機能しました。

@kszymanski 「certificateSecretUrl」に何を設定しましたか？ URLの「some-id」は、KeyVaultの証明書オブジェクトの「バージョン」である必要があります。 残念ながら、これは「azkeyvault証明書リスト--vault-name ...」によっても、Powershellの「Get-AzKeyVaultSecret」または「Get-AzKeyVaultCertificate」によっても返されませんが、KeyVaultで証明書を見るとポータルに表示されます。

「壊れた」証明書が作成されたため、上記と同じ誤解を招くエラーが発生しました。 正しいIDを見つけたら、それは機能しました。

ここでは難読化されています。 ポータルからIDを設定していますが、証明書識別子と秘密識別子の両方を試しましたが、どちらの場合もうまくいきませんでした。 また、前述のように、生データとパスワード（完全に削除されたKey Vault参照）を使用して証明書を設定しても、同じエラーは何も変更されません。 したがって、キーボールト証明書のURLではなくIDの割り当てに問題がある可能性があると思います。

KeyVaultを機能させることができなかったため、最終的にKeyVaultを使用する代わりに、証明書とパスワードを手動でアップロードする必要がありました。 ただし、このエラーが発生したときにポータルから実行している場合は、他の誰かが言及したように、新しいアプリケーションゲートウェイを作成する必要があります。 何らかの理由で、エラーが発生したゲートウェイを調整できなくなります。

ご覧のとおり、ARMテンプレートから何度も作成しています。 そして、作成後に手動で変更を加えます。 次に、ポータルで、このIDと証明書を問題なく割り当てることができます。

@kylehayesそれは完全に正しくありません。 はい、現在ポータルから失敗状態から抜け出すことはできませんが、PowerShellまたはCLIからそれを行うことはできます。

例えば。 失敗したリスナー、ルール、および証明書を削除し、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

ネットワークファイアウォールが構成された新しいKVでも同じ問題が発生しました。 ファイアウォールをオフにした後のテストとして、ARM展開でエラーが発生しました。 私も、クライアントがKVをロックダウンしたいので、これが機能する必要があることに同意します。

1. 90日以外のソフト削除（保持）期間にはまだ問題があります。 この場合、エラーは「_The 『UserAssignedIdentities』プロパティキーのみ空のJSONオブジェクト、nullまたはなければならないリソースproperty._をexisiting」（ところで、このエラーメッセージのタイプミスがある。）回避策セットKVオブジェクトプロパティにあります'softDeleteRetentionInDays'を90にします。これにはhttps://resources.azure.com/を使用できます。

2. App GW管理プレーンは、AzureDC内のいくつかのランダムなIPを使用してKVにアクセスします。 https://github.com/MicrosoftDocs/azure-docs/issues/48866を参照して

したがって、ポータルから「壊れた」アプリGWを修正するには、次のことを行う必要があります。

1. KVソフト削除期間が90日であることを確認してください
2. KVファイアウォールが無効になっている
3. AppGW構成オブジェクトの更新をトリガーするポータルで管理アクションを実行します

残念ながら、証明書オブジェクトはポータルのUIに公開されていないため、PSを使用してKV内の証明書へのリンクから構成オブジェクトをクリーンアップする必要があります。

このKV / AppGW統合ストーリー全体は、リリースされる前にさらにテストする必要がありました。

同じ症状が発生しました（「 'UserAssignedIdentities'プロパティキーは空のjsonオブジェクト、null、またはリソースが存在するプロパティのみである必要があります。」）、ソフト削除期間は90日で、ファイアウォールが開いています。 KVは「永続的な」リソースグループにあり、アプリケーションスタックは一時的なグループにあります。 1週間前にDEVスタックを破棄し、（ARMを介して）バックアップしようとすると、Application Gatewayでプロセスが失敗します。つまり、これが再び機能するまで開発を行うことはできません。

ARMテンプレートからの展開中にも同じ問題が発生し、90日間ソフト削除を続け、すべてのネットワークでファイアウォールを開いたままにしましたが、それでも同じ問題に直面しています。ポータルからは機能しますが、ARMテンプレートからは機能しません。
。 'UserAssignedIdentities'プロパティキーは、空のjsonオブジェクト、null、またはリソースが存在するプロパティのみである必要があります。

同じappgatewayがla-la-landに行くのはこれが3回目です。 カントストップおよび/または更新：
{{
「エラー」：{
"コード"： "MissingIdentityIds"、
"メッセージ"： "'UserAssigned'IDタイプのIDIDはnullまたは空であってはなりません。"
}
}

正直に言うと。 不安定なので諦めました。

15:46の木、2020年4月23日にpererap01 [email protected]書きました：

同じappgatewayがla-la-landに行くのはこれが3回目です。 カントストップと
または更新：
{{
「エラー」：{
"コード"： "MissingIdentityIds"、
"メッセージ"： "'UserAssigned'のIDIDをnullまたは空にすることはできません
IDタイプ。」
}
}

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/MicrosoftDocs/azure-docs/issues/33157#issuecomment-618624144 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/ABD32Z2KPUY7KBFNPTCVMA3ROCLJ3ANCNFSM4HXFRP4A
。

元のものは薄片状なので、別のものを立ててこれを使用する必要がありました！ この問題に関するMSのチケットを持っています...今回解決されるかどうか見てみましょう。

@ SubhashVasarapu-MSFTには、そのような矛盾が発生している理由を潜在的なブロッカーを一覧表示する方法がありますか？ 根本的な原因/制限である可能性があります。

修正で現在のステータスを取得するとさらに良いでしょう。

このスレッドの他の人と同じように、私もエラーが発生しました：

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

キーボールトのアクセスポリシーで、Azure Gatewayで使用されるマネージIDのすべてのキー、シークレット、および証明書のアクセス許可を有効にしました。 これはやり過ぎだと確信していますが、他の権限を組み合わせて試した後、イライラしてすべてを有効にしました。 その後、エラーはなくなりました。

クラウドでプロビジョニングされた証明書を使用しているときのPSe2e TLSは、非常に一般的なシナリオです。 Azureの初心者として、これがまだ洗練されたエクスペリエンスではないことに非常に失望しています。

KeyVaultからApplicationGatewayを介してクラスターにシークレットと証明書をフェッチしようとしましたが、KVに対して認証できず、Bad Gatewayエラーが発生するため、アプリケーションが失敗します。

接続ID "0HM0BI3H5TUJP"、要求ID "0HM0BI3H5 TUJP：00000001 "：未処理の例外がアプリケーションによってスローされました。
接続ID "0HM0BI3H5TUNQ"、要求ID "0HM0BI3H5 TUNQ：00000002 "：未処理の例外がアプリケーションによってスローされました。

シークレットを取得しようとしているポッドのログにこれらのエラーが表示されます。

My KeyVaultではソフト削除が有効になっており、デフォルトの90日が保持期間として設定され、ネットワークがすべてのネットワークに設定されています。 My App GatewayIdentityもVaultに正しく構成されています。 誰かが私がどこで間違っているのか知っていますか？

私はMSのエンジニアと仕事をしています
これは私が見つけたものの要約です

1. Appgatewayリスナーに関連付けられている証明書をすべて削除します。 基本的に、appgatewayにインストールされているすべての証明書を削除します
   チェックする：PS
   az network application-gateway ssl-cert list -g（リソースグループ）-gateway-name（ゲートウェイ名）
   以下が表示された場合
   "keyVaultSecretId"：null、
   証明書はappgatewayにインストールされ、ほとんどの関連付けが解除されます
2. 証明書がappgatewayにない場合は、キーボールトから証明書を関連付ければ機能するはずです。

私はMSのエンジニアと仕事をしています
これは私が見つけたものの要約です

1. Appgatewayリスナーに関連付けられている証明書をすべて削除します。 基本的に、appgatewayにインストールされているすべての証明書を削除します
   チェックする：PS
   az network application-gateway ssl-cert list -g（リソースグループ）-gateway-name（ゲートウェイ名）
   以下が表示された場合
   "keyVaultSecretId"：null、
   証明書はappgatewayにインストールされ、ほとんどの関連付けが解除されます
2. 証明書がappgatewayにない場合は、キーボールトから証明書を関連付ければ機能するはずです。

これは私のシナリオでは当てはまりません。アプリケーションゲートウェイを含むリソースグループ全体が破棄されて再作成されたためですが、この問題は引き続き発生します。

それから私の仮定は、キーボールトとそれがapgatewayとどのように通信するかに問題があるということです...
リソースマネージャーを確認してgetリクエストを実行しましたか？エラー処理が改善されたり、デバッグモードで実行されたりする可能性があります

現時点ではKeyVault自体には触れていないため、MSサポートはKeyVaultを現在の状態で確認できます。

エラーメッセージはどこから生成されますか？ WAFが有効になっているバージョン2ですか？

はい、V2WAFです。 ARMからエラーが発生します。 AZCLIを使用してADOでホストされているWindowsエージェントから実行

az group deployment create --debug --mode Complete

注：ARMテンプレートには、スタック全体、VNET、VM、APGなどが含まれます。KeyVaultなどを使用すると、別のリソースグループに保持されます。

ああ、わかりました…。

差出人：継続的デリバリー自動化フレームワーク[email protected]
送信：2020年6月8日月曜日午後1時1分
宛先：MicrosoftDocs / azure-docs [email protected]
Cc：Perera、Priyantha、Arvato SCS [email protected] ; コメント[email protected]
件名：Re：[MicrosoftDocs / azure-docs]アプリケーションゲートウェイ：Key Vaultとの統合が機能しない（＃33157）

はい、V2WAFです。 ARMからエラーが発生します。 AZCLIを使用してADOでホストされているWindowsエージェントから実行

az group Deployment create --debug --mode Complete

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してくださいhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F33157%23issuecomment-640855594&data = 0.02％7C01％7C％7C742cf0b3589c42d4021508d80be6b732％7C1ca8bd943c974fc68955bad266b43f0b％7C0％7C0％7C637272432826294946＆SDATA = qdtJwYk5QV8evtt8Bp％2B1％2Bn7lkz5ebEG％2BCMAfdQVmSS4％3D＆予約= 0 、または解除https://eur02.safelinks.protection.outlook.com/?url=https%図3A％2F％2Fgithub.com％2Fnotifications％2Funsubscribe-認証％の2FAF2ZC6CPCTZUSOKGAT7F523RVU7RBANCNFSM4HXFRP4A＆データ= 0.02％7C01％7C％7C742cf0b3589c42d4021508d80be6b732％7C1ca8bd943c974fc68955bad266b43f0b％7C0％7C0％7C637272432826304943＆SDATA = TgPtoOi5neDLlb％2B0hk％2BEULQyZSUFV8fy4deb9RgUsKk％3D＆= 0予約。

@ pererap01
「--modeComplete」を使用しています。これにより、テンプレートで定義されていない「非表示」のリソースが削除される可能性があります。
また、デプロイメントを実行するユーザー/サービスプリンシパルは、このMSIがデプロイメントの一部でない場合、WAFを使用してKVにアクセスするMSIを読み取る機能を備えている必要があります。

@gaikovoi 、参考になったと思います。 同じARMを使用し、3つの環境で実行しましたが、すべて正常に機能しました。 DEV環境は毎週金曜日に解体され、毎週月曜日に再作成されたため、チームは1週間を通して作業できる新しい環境を用意しました（DEVの1つが混乱した場合は、アドホックな分解/スタンドアップを行うことがありました）。 展開の他の側面は変更されていませんが、1週間は表示されませんでした。

@cdaf今日ARMの問題がありました
解決済み：RCA -Azure ResourceManager-リソースの作成または削除の失敗

とにかく、時々、ARMの展開は意味のある理由なしに失敗します。 これは通常、AzDOパイプラインを再実行することで修正されます。

@gaikovoi 、はい、ARMは非常に気質的である可能性があります（特にARMを介してAPIMをデプロイしようとした場合）が、ここではそうではなく、30回近く再試行されています（さまざまな人が診断しようとしています）

こんにちは、みんな。 とてもイライラしたので、これに対応するためだけにアカウントを作成しました。 私が好きな人、KeyVaultをすべてのネットワークに設定できない、または設定したくない人のために...回避策を見つけました。 リソースエクスプローラーに移動して以下を削除すると、AppGatewayが再び満足するはずです。

1. IDオブジェクトを削除します
2. sslCertificatesで失敗の原因となった証明書を削除します
3. 失敗したリスナーのすべてのオカレンスを削除します
4. 変更を加えます

これにより、すぐにApp Gatewayが更新され、正常なプロビジョニング状態になりました。 確かに、KeyVault統合を試みるには、プロセスに燃え尽きてイライラしすぎたので、証明書をApp Gatewayに直接アップロードしただけで、正常に機能しました。 KeyVault統合は本当にMicrosoftによって修正される必要があります...

誰でも、それが誰かを助けることを願っています。

乾杯。

上記のすべてをエコーするだけです。 この問題は間違いなくAzureに存在し、正直に言って私の心を打たれます。

AZUREから購入したワイルドカード証明書のアクセス許可を管理するために管理対象IDを追加した後、文書化されたすべての手順に従ってこの証明書をゲートウェイに追加した後も、IDがボールトにアクセスできないことを示すエラーが発生します。 ボールトと証明書の両方をチェックして、実際にアクセスできることを確認します。 権限を単純な読み取り専用から所有者に昇格させて、これで問題が解決するかどうかを確認し、ワイルドカード証明書のロックに関するエラーをヒットすることを決定します。

そのため、Key Vaultメソッドを使用して証明書を追加できないだけでなく、複数の構成を試した後、アイテムをクリーンアップしたりIDのアクセス許可を変更したりしようとすると、AzureからIDを削除することもできません。クライアントが購入したワイルドカード証明書。 正直なところ、ここで見つけた最も簡単な方法は、証明書をエクスポートし、.pfxファイルにパスワードを追加して、ゲートウェイの作成中に最後に再アップロードすることです。 これはすべて、Terraformを介したプロビジョニング中に使用する正しいARMテンプレートを生成することを期待して、GUIを介して行われました。 まだ壊れています。

これは、Azureが無視できる非常に基本的なことのようです。

なんと絶対的な悪夢-私は1年以上のフィードバックと問題を信じることができず、これはまだ修正されていません。 キーボールトはすべてのネットワークに公開されており、ソフト削除が有効になって90日に設定され、2つをリンクする最初の試みでゲートウェイが中断されました。

これは本当にひどく壊れた製品です。 😠

こっちも一緒。 どうしてこれが1年以上の未解決の問題になるのでしょうか。 App Gateway WAFv2を使用するのは恐ろしいことです。
これはいつ修正されますか？

それでも問題！ 私の場合、それはkeyvaultネットワーク統合のようです。 ポータルは間違いなくそれをチェックせず、ランダムなプロパティキーエラーで失敗します（予想されるような禁止されたエラーではありません）。 ゲートウェイサブネットでMicrosoft.KeyvaultのVNETサービスエンドポイントを有効にすると、この統合がKeyVault FWを有効にして機能するかどうかを誰かが確認できますか？

GWにアップロードされた既存の証明書を「更新または編集」しようとしました+ FWを有効にしてPAASKVを使用します+ IPWhitelistを有効にします

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.

（上記の同じリスナーで）GWにアップロードされた既存の証明書を「更新または編集」しようとしました+ FWを無効にしてPAASKVを使用します

• 成功

_別のリスナーで_
GWにアップロードされた既存の証明書を「更新または編集」しようとしました+ FWDISABLEDでPAASKVを使用します

• 成功

こんにちは、みんな。 とてもイライラしたので、これに対応するためだけにアカウントを作成しました。 私が好きな人、KeyVaultをすべてのネットワークに設定できない、または設定したくない人のために...回避策を見つけました。 リソースエクスプローラーに移動して以下を削除すると、AppGatewayが再び満足するはずです。

1. IDオブジェクトを削除します
2. sslCertificatesで失敗の原因となった証明書を削除します
3. 失敗したリスナーのすべてのオカレンスを削除します
4. 変更を加えます

これにより、すぐにApp Gatewayが更新され、正常なプロビジョニング状態になりました。 確かに、KeyVault統合を試みるには、プロセスに燃え尽きてイライラしすぎたので、証明書をApp Gatewayに直接アップロードしただけで、正常に機能しました。 KeyVault統合は本当にMicrosoftによって修正される必要があります...

誰でも、それが誰かを助けることを願っています。

乾杯。

同じ状況で！ Key Vaultをサブネットに制限する必要があるため、証明書を直接追加し、KeyVaultは使用しません。
乾杯、ルイ

バンプ！ これは、Terraformを使用した場合にも問題になります。 KVでファイアウォールがオンになっている場合、AppGWプロビジョニングは失敗します。

すでに多くのことを試しました：

• KVでオン
  
  
  
  • テンプレート展開用のAzureResource Manager
  
  
  • 信頼できるMicrosoftサービスがこのファイアウォールをバイパスすることを許可しますか？
  
  
• AppGWサブネット上のサービスエンドポイントとKVFWへのネットワークの追加
• AppGWのpublicIPをKVFWに追加する

...どれも機能しません。 唯一の解決策は、キーボールトのファイアウォールを無効にすることです。

また、この問題があります。 調査してください！

それでも問題！ 私の場合、それはkeyvaultネットワーク統合のようです。 ポータルは間違いなくそれをチェックせず、ランダムなプロパティキーエラーで失敗します（予想されるような禁止されたエラーではありません）。 ゲートウェイサブネットでMicrosoft.KeyvaultのVNETサービスエンドポイントを有効にすると、この統合がKeyVault FWを有効にして機能するかどうかを誰かが確認できますか？

GWにアップロードされた既存の証明書を「更新または編集」しようとしました+ FWを有効にしてPAASKVを使用します+ IPWhitelistを有効にします

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.

（上記の同じリスナーで）GWにアップロードされた既存の証明書を「更新または編集」しようとしました+ FWを無効にしてPAASKVを使用します

* SUCCESS

_別のリスナーで_
GWにアップロードされた既存の証明書を「更新または編集」しようとしました+ FWDISABLEDでPAASKVを使用します

* SUCCESS

私にはうまくいかないようです。 私もたくさんの組み合わせを試しました。 唯一の解決策は、KVファイアウォールも完全に無効にすることでした。

これは私にも当てはまるようです。 keyvaultファイアウォールを完全に無効にするだけで、これが機能します。

私にも同じ問題があります...どうしてこれをまだ解決できないのですか？

わかりません-私たちもこれに遭遇しました。 ここでの適切な構成は何ですか？

Azureサポートでチケットを開いた後、私は彼らの公式の回答を受け取りました：
「会話中に説明したように、Key Vaultが「パブリックエンドポイント（すべてのネットワーク）」アクセスを許可するように構成されていない場合、ApplicationGatewayは現在KeyVaultとの統合をサポートしていません。
現在、Application Gatewayとの統合に関して、KeyVaultのすべてのネットワーク構成をサポートするために必要なチームと社内で協力しています。

これに関する公式文書は近日公開されます。」

@lonevvolfすべてのネットワークに対してkeyvaultを開き、管理されたIDでSSL証明書をリスナーにバインドしてから、keyvaultをファイアウォールで保護する（またはvnetにロックする）ことができます。Appgwは引き続き_cached_ ssl証明書を使用しますが、有効期限が切れる前にkeyvault内の証明書を置き換えると、appgwは更新された証明書にロールオーバーできなくなります。 だから、あなたはそれについて注意しなければなりません。 しかし、ええ、それは壊れています。

@Microsoftこの問題に関する最新情報を入手できますか？ それはまだ解決されておらず、エンタープライズAzureのお客様はKeyVaultをすべてのネットワークに公開する必要があります。 これが報告されてから1年以上が経過しましたが、ロードマップに載せるには十分な時間があります。

会話中に説明したように、Key Vaultが「パブリックエンドポイント（すべてのネットワーク）」アクセスを許可するように構成されていない場合、ApplicationGatewayは現在KeyVaultとの統合をサポートしていません。
現在、Application Gatewayとの統合に関して、KeyVaultのすべてのネットワーク構成をサポートするために必要なチームと社内で協力しています。

また、この制限はどこかに文書化する必要があります。 このステートメントをMSFTドキュメントのどこかに入れることができますか？

たとえば、このドキュメントには次のステートメントが含まれている必要があります： //docs.microsoft.com/en-us/azure/application-gateway/key-vault-certs

あなたが言ったように@oising "あなたはすべてのネットワークにkeyvaultを開き、管理されたIDでSSL証明書をリスナーにバインドし、次にkeyvaultをファイアウォールで保護する（またはvnetにロックする）ことができます。Appgwはキャッシュされたssl証明書で引き続き機能します。」

az cliはこの機能をサポートしていますか？ az cliを使用してssl証明書（キーボールト証明書からプル）を使用してAppゲートウェイでhttpリスナーを作成できますか？ もしそうなら、azcliコマンドを提供してください。 前もって感謝します。

@lonevvolfすべてのネットワークに対してkeyvaultを開き、管理されたIDでSSL証明書をリスナーにバインドしてから、keyvaultをファイアウォールで保護する（またはvnetにロックする）ことができます。Appgwは引き続き_cached_ ssl証明書を使用しますが、有効期限が切れる前にkeyvault内の証明書を置き換えると、appgwは更新された証明書にロールオーバーできなくなります。 だから、あなたはそれについて注意しなければなりません。 しかし、ええ、それは壊れています。

うーん。 更新された証明書をインストールする前にKeyVaultファイアウォールをオフにし、その後再びオンにした場合はどうなりますか？ AGWは変更を確認し、ファイアウォールがダウンしている間に新しい証明書をすぐに取得しますか？ 私は現在、certbot / Let'sEncryptを使用してKeyVaultで証明書の更新を処理するタイマー付きのAzure関数に取り組んでいます。 Key Vaultで証明書が更新されている間、Key Vaultファイアウォールを無効にしてから再度有効にするために、いくつかのazコマンドをスクリプト化できるはずです。

これのいずれかが必要でさえあるのはばかげています。 ：/

キーボールト->「プライベートエンドポイントと選択したネットワーク」でFWをサポートする計画があるかどうか誰かが知っていますか？

他の人の感情を反映するために別のコメントを追加します。 Key Vaultのすべてのネットワークを公開することは、多くの組織にとって解決策ではないことが多いため、この問題は非常に苛立たしいものです。 私はTerraformを使用してこれに遭遇しており、現在それを回避する必要があります。 @microsoftからの修正は

私も同じですが、インターネットkvやappgwを利用することはできず、この機能を必要なだけ使用することもできません。 ：/

今日も同じ問題を抱えています。 :(

appgwとの闘いに腹を立てている人々にとって、もう1つの実行可能なオプションは、Azure Frontdoor（基本的には縮小されたappgw）を使用することですが、パブリックネットワーク（vnetなし）でのみ機能します。これは、公開されているSSL証明書を自動生成できます。

プライベートエンドポイントと選択したネットワークアクセスのみを許可するように設定されたKeyVaultとAppGWが連携できるように積極的に取り組んでいます。 @jmcshaneの提案ドキュメントを更新しました。 AppGWがすべてのKeyVault構成をサポートできるようになったら、このスレッドとドキュメントを更新します。

動作する可能性のある

次の手順に従ってこれを修正できました。

• az network application-gateway ssl-certremoveを使用して既存のssl-certプロファイルを
• ファイアウォールを一時的に無効にし、すべてのネットワークからのアクセスを許可します
• Azure Key Vaultから証明書を再度バインドします（すべてのサービスIDアクセス許可に問題がないことを2回確認しました）。
• すべてのネットワークからのアクセスを再度無効にする

すべて正常に動作しています

注：上記の回避策はお勧めしません。 Microsoftは、この方法が使用され、ファイアウォールが再び有効になったため、ApplicationGatewayでの今後の自動スケーリング操作が失敗することを警告しています。 これには、Microsoftによる完全な修正が本当に必要です。