Skip to content

← All integrations

Cloud service

Uploads the certificate to a web app and binds it to its custom host names.

The appliance runs the package and connects to Azure App Service through Azure Resource Manager over HTTPS on port 443. No agent is installed on Azure App Service.

What happens

  1. The appliance connects to Azure App Service through Azure Resource Manager on port 443.
  2. Discovery selects the subscription, resource group, web app and hostname. PFX hostname coverage is checked before changes. An existing certificate with the same thumbprint is reused when its region and App Service plan match; otherwise a separate certificate is uploaded.
  3. The certificate is bound to the selected hostname. Without AZURE_SSL_TYPE, an enabled binding keeps its SSL type; an unbound hostname gets SNI. Previous bindings are saved in a protected recovery journal. If it fails: Recovery and rollback reread ARM and restore only bindings that still match the deployment. Observed operator edits and shared certificate objects are preserved. An interrupted change is reconciled with the journal before another switch.
  4. Verification reads the SSL type and thumbprint back through ARM. It checks the binding, not served TLS, application health or deployment propagation.

Technical details

Connection
The package runs on the appliance, which connects over HTTPS to Azure Resource Manager, port 443. No agent is installed.
You need
Service principal with client ID, client secret and tenant ID. Needs web app, certificate and hostname read access plus certificate and hostname-binding write access; certificate deletion is not used.
Actions
Discovery, Installation, Verification, Rollback, Removal
Packages
azure-appservice-api
Note
  • Removal disables TLS on selected bindings and retains custom domains and shared certificates. Keep the recovery journal in CERTOPS_BACKUP_DIR or the account’s .sslbrain/azure-appservice-backups for rollback. A local lock protects this agent’s runs but does not lock Azure Portal or other appliances.
  • Management TLS checks the trust chain and hostname by default. MANAGEMENT_TLS_CA_BUNDLE uses a CA file; MANAGEMENT_TLS_PIN_SHA256 accepts exactly the saved certificate on both login.microsoftonline.com and management.azure.com. Use system trust or a CA when those hosts have different certificates. MANAGEMENT_TLS_INSECURE is an explicit opt-out with a warning; AZURE_TLS_CA_BUNDLE and AZURE_TLS_INSECURE remain aliases.

Get started