Ошибка ERR_SSL_UNRECOGNIZED_NAME_ALERT из шлюза приложений Azure с сертификатом SSL в хранилище ключей другой подписки

Я настроил шлюз приложений и хранилище ключей с помощью Terraform. Кажется, что со шлюзом приложений все работает, если я храню сертификат локально, но если я настрою его на использование сертификата из хранилища ключей, а затем перейду на сайт, я получу ошибку ERR_SSL_UNRECOGNIZED_NAME_ALERT, подразумевающую, что прослушиватель отключен. Я видел, как другие сообщали о подобных проблемах (например, Шлюз приложений Azure, как подключиться к SSL-сертификату в другой подписке Azure?); хотя ни один из ответов мне не помог / некоторые уже устарели.

• Хотя пользовательский интерфейс портала Azure не поддерживает хранилище ключей в другой подписке, сама Azure поддерживает (сопутствующая документация); поэтому я смог установить сертификат через TerraForm.
  • Примечание: я также вручную загрузил сертификат непосредственно в AppGW, используя портал, чтобы доказать, что все работает, когда сертификат был локальным; так оно и было.
  • Примечание 2. Затем я использовал PowerShell, чтобы вернуть значение к использованию Key Vault на случай возникновения какой-либо проблемы с Terraform; но использование PowerShell дало тот же результат (т. е. успешно обновило конфигурацию, но привело к повторному появлению исключения ERR_SSL_UNRECOGNIZED_NAME_ALERT). Set-AzApplicationGatewaySslCertificate -ApplicationGateway $appGw -Name 'wildcard-example-com' -KeyVaultSecretId 'https://myKeyVault.vault.azure.net/secrets/wildcard-example-com/' -Verbose | Set-AzApplicationGateway -Verbose
• Все ресурсы находятся в одном регионе (UK South).
• Мой шлюз приложений подключен к виртуальной сети.
  • Эта ассоциация настраивается путем передачи идентификатора подсети в блок шлюз_ip_configuration.
  • Виртуальная сеть подключена к нашему VHub.
  • Существует правило маршрутизации, гарантирующее, что трафик к частным диапазонам IP-адресов направляется через наше встроенное ПО (где мы размещаем правила для внутреннего трафика), в то время как трафик к общедоступным диапазонам идет напрямую в Интернет согласно документам.
  • Не существует правил для блокировки трафика между AppGW и FW (в соответствующих подсетях не настроены NSG, нет правил, которые бы влияли на это в FW; журналы FW не показывают трафик между AppGW и KeyVault (запрещен или нет), однако у нас включено полное ведение журнала).
  • С подсетью связан Microsoft.KeyVault service endpoint
  • Наши внутренние DNS-серверы связаны с виртуальной сетью/они правильно определяют внутренний IP-адрес хранилища ключей (т. е. показывают, что условные серверы пересылки и частные DNS-зоны для хранилища ключей настроены правильно).
• Мое хранилище ключей подключено к другой виртуальной сети.
  • Хранилище ключей подключено к этой виртуальной сети через частную конечную точку.
  • В хранилище ключей установлены Disable public access и Allow trusted Microsoft services to bypass this firewall.
  • Эта виртуальная сеть также соединена с VHub, при этом весь трафик маршрутизируется через микропрограмму (т. е. подключения к другим виртуальным сетям и из них будут проходить через микропрограмму, а также общедоступный выход; общедоступный вход отсутствует, поскольку он блокируется сетью хранилища ключей). конфигурацию, как указано выше).
• AppGW имеет управляемое удостоверение, связанное
• Это управляемое удостоверение настроено в политике доступа к хранилищу ключей с разрешениями get для секретов (фактически, в настоящее время я предоставил все доступные разрешения, просто чтобы не учитывать политики безопасности как потенциальную причину). Примечание: я использую vault access policy; нет RBAC.
• Путь, используемый в настройке SSL-сертификата шлюза приложений, правильный, т. е. не содержит опечаток, указывает на правильное хранилище ключей, указывает на путь /secrets/ и не включает информацию о версии.

Есть ли что-то, что я пропустил, или могу ли я предпринять какие-либо шаги по отладке, чтобы получить дополнительную информацию о том, почему AppGW не может загрузить этот сертификат из KeyVault?