Как отличить штатное хранение App Service Certificate от нативного Key Vault certificate, проверить provider permissions и issuance state, не создавая лишний объект сертификата.
Определите, откуда появился сертификат
Сначала установите тип ресурса-источника: App Service Certificate, созданный через App Service, или нативный certificate в Key Vault. Внешне оба связаны с TLS и vault, но используют разные объектные модели. Microsoft для App Service Certificate прямо указывает хранение сертификата в Key Vault как secret. Поэтому отсутствие отдельной записи в разделе Certificates не доказывает неудачный выпуск. Зафиксируйте resource type, subscription, vault и issuance status без содержимого secret. Только после этого сравнивайте увиденное с правильной документацией.
Сравните модели secret и native certificate
Нативный Key Vault certificate создаёт адресуемые объекты certificate и key, а также secret с материалом сертификата. App Service Certificate опирается на secret в vault и на собственный ресурс App Service. Матрица проста: источник, ожидаемые объекты, кто обновляет материал и какой сервис его потребляет. Если источник — App Service Certificate и secret присутствует, само по себе отсутствие certificate object соответствует описанной модели. Если ожидался именно нативный Key Vault certificate, проверьте, тем ли способом он создавался, а не пытайтесь вручную дублировать материал.
Проверьте issuance и разрешения provider
Для App Service Certificate Microsoft документирует требования к доступу resource provider к Key Vault. Сверьте состояние выпуска, наличие актуальной версии secret и права provider на выбранный vault. Не выводите значение secret и не копируйте его в отчёт. Если certificate issued, secret доступен сервису и binding использует ожидаемый thumbprint, модель работает даже без отдельного certificate object. Если secret отсутствует или provider не имеет нужного доступа, исправляйте конкретное несоответствие и повторяйте одну проверку, а не пересоздавайте весь vault.
Создавайте второй объект только при явной необходимости
Отдельный native certificate может понадобиться другому приложению, которое использует именно Key Vault Certificates API, но это новое архитектурное требование, а не обязательный ремонт App Service Certificate. До такого решения уточните, какой API читает потребитель, как будет обновляться версия и кто отвечает за rotation. Не экспортируйте private key в незащищённые файлы и не меняйте access model vault ради интерфейсного сходства. Для поддержки соберите resource IDs, issuance state, secret version metadata и provider permission result без секретного содержимого. Критерий остановки — ожидание объекта, не указанного в выбранной модели.
Материал подготовлен редакцией VOne с применением ИИ для структурирования; факты вручную сверены с официальной документацией Microsoft, а форумная ветка использована только как обезличенный сигнал боли.
Источники и проверка
- Microsoft Learn — Configure App Service Certificate проверено 2026-07-31
- Microsoft Learn — About Azure Key Vault certificates проверено 2026-07-31
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.