Skip to content
Docs sslbrain sslbrain.com

Azure Front Door

Copy link to the page “Azure Front Door”

← All integrations

Cloud service

Renews certificates on selected Azure Front Door custom domains through Key Vault, with TLS checks and rollback.

The appliance runs the package and connects to Azure Front Door through Azure Resource Manager / Key Vault over HTTPS on port 443. No agent is installed on Azure Front Door.

What happens

  1. The appliance connects to Azure Front Door through Azure Resource Manager / Key Vault on port 443.
  2. Set AZURE_RESOURCE_ID for the profile or Classic Front Door and frontdoor-custom-domain as AZURE_TARGET_ROLE. Select an existing domain with AZURE_TARGET_NAME; discovery reads its TLS settings and routes.
  3. Import the certificate into a separate Key Vault certificate object, or select an existing reference with AZURE_KEY_VAULT_SECRET_ID. Set AZURE_KEY_VAULT_RESOURCE_ID if the domain has no existing customer-managed vault reference. Standard/Premium receives a separate profile secret; Classic enables HTTPS with an exact certificate version. If it fails: On failure, rollback attempts to restore the previously served certificate on the selected target. Restoration failure is reported with backup_dir for recovery.
  4. The appliance checks that the target serves the new leaf and full intermediate chain, with the correct hostname and validity.

Technical details

Connection
The package runs on the appliance, which connects over HTTPS to Azure Resource Manager / Key Vault, port 443. No agent is installed.
You need
Service principal with tenant ID, client ID and secret, ARM read/write and operation-status access to the profile/domain and profile secrets. Automation needs vault ARM read, certificate import/get and secret get; secret list for version lookup. The vault must be in the same subscription. Front Door also needs its own vault access: managed identity or service principal for Standard/Premium, Microsoft.Azure.Frontdoor with certificate Get and secret Get for Classic. A vault firewall must allow Front Door access through the documented trusted-service setting.
Platform
Front Door Standard, Premium and Classic; discovery selects the API path.
Actions
Discovery, Installation, Verification, Rollback
Packages
azure-appgateway-api 1.0.0
Note
  • Use a valid RSA certificate covering the domain hostname, with the leaf and full intermediate chain to a root on Microsoft’s Trusted CA List. The certificate must be a PFX-backed Key Vault certificate object. The appliance must reach Azure OAuth/ARM/Key Vault over HTTPS and the domain TLS port.
  • The domain must already exist with the required validation and route association in Azure. The agent changes the certificate binding; DNS, routes, origins, identities and access policies remain under your administration. Restoring a Microsoft-managed certificate can require domain validation and reissuance. Rollback reports failure if the previous leaf is not served before the deadline.
  • Management HTTPS uses system CA trust. MANAGEMENT_TLS_CA_BUNDLE_BASE64, MANAGEMENT_TLS_PIN_SHA256 and MANAGEMENT_TLS_INSECURE are optional settings. One pin must match OAuth, ARM and Key Vault peers at once; use CA trust for different certificates. Served-certificate trust is selected separately with AZURE_VERIFY_CA_BUNDLE.
  • AZURE_OPERATION_TIMEOUT defaults to 1800 seconds and AZURE_VERIFY_TIMEOUT to 300 seconds; both can be increased to 86400. Verification covers the selected TLS probes. Deploy stores backup_dir under the appliance data-volume HOME for verify and rollback; retain that directory for your rollback period. New certificate objects are retained; plan cleanup after your rollback retention period.
  • An independent verify uses the retained backup_dir and attempts to restore the previously selected binding if the TLS probe fails at the deadline, even when ARM still shows the new binding.

Get started