Gå til indhold

← Alle integrationer

Cloud-tjeneste

Uploader certifikatet til en web-app og binder det til dens egne værtsnavne.

Appliancen kører pakken og forbinder til Azure App Service gennem Azure Resource Manager over HTTPS på port 443. Der installeres ingen agent på Azure App Service.

Sådan forløber det

  1. Appliancen forbinder til Azure App Service gennem Azure Resource Manager på port 443.
  2. Discovery vælger subscription, resource group, web-app og værtsnavn. PFX-certifikatets navnedækning kontrolleres før ændringer. Et eksisterende certifikat med samme thumbprint genbruges, når region og App Service-plan passer; ellers uploades et separat certifikat.
  3. Certifikatet bindes til det valgte værtsnavn. Uden AZURE_SSL_TYPE bevares en aktiv bindings SSL-type; et ubundet værtsnavn får SNI. Tidligere bindinger gemmes i en beskyttet gendannelsesjournal. Hvis det fejler: Gendannelse og rollback genlæser ARM og gendanner kun bindinger, der stadig svarer til installationen. Observerede operatørændringer og delte certifikatobjekter bevares. En afbrudt ændring afstemmes med journalen før næste skift.
  4. Kontrol læser SSL-type og thumbprint tilbage via ARM. Den kontrollerer bindingen, ikke det serverede TLS-certifikat, applikationens helbred eller udrulningens propagation.

Tekniske detaljer

Forbindelse
Pakken kører på appliancen, som forbinder over HTTPS til Azure Resource Manager, port 443. Der installeres ingen agent.
I skal bruge
Service principal med klient-id, client secret og tenant-id. Kræver læseadgang til web-app, certifikater og værtsnavne, skriveadgang til certifikater og værtsnavnebindinger; certifikatsletning bruges ikke.
Handlinger
Discovery, Installation, Kontrol, Rollback, Fjernelse
Pakker
azure-appservice-api
Bemærk
  • Fjernelse slår TLS fra på de valgte bindinger og bevarer custom domains og delte certifikater. Behold gendannelsesjournalen i CERTOPS_BACKUP_DIR eller kontoens .sslbrain/azure-appservice-backups til rollback. En lokal lås beskytter denne agents kørsler, men låser ikke Azure Portal eller andre appliances.
  • Management-TLS kontrollerer som standard tillidskæde og værtsnavn. MANAGEMENT_TLS_CA_BUNDLE bruger en CA-fil; MANAGEMENT_TLS_PIN_SHA256 accepterer præcis det gemte certifikat på både login.microsoftonline.com og management.azure.com. Brug systemtillid eller CA, når de to værter har forskellige certifikater. MANAGEMENT_TLS_INSECURE er et eksplicit fravalg med advarsel; AZURE_TLS_CA_BUNDLE og AZURE_TLS_INSECURE bevares som aliaser.

Kom i gang