Azure Front Door
Kopiér link til siden “Azure Front Door”
Fornyer certifikatet på et valgt Azure Front Door custom domain via Key Vault med TLS-kontrol og rollback.
Sådan forløber det
- Appliancen forbinder til Azure Front Door gennem Azure Resource Manager / Key Vault på port 443.
- Angiv AZURE_RESOURCE_ID for profilen eller Classic Front Door og frontdoor-custom-domain som AZURE_TARGET_ROLE. Vælg et eksisterende domæne med AZURE_TARGET_NAME; discovery læser dets TLS-indstillinger og routes.
- Importér certifikatet i et separat Key Vault-certifikatobjekt, eller vælg en eksisterende reference med AZURE_KEY_VAULT_SECRET_ID. Angiv AZURE_KEY_VAULT_RESOURCE_ID, hvis domænet ikke allerede har en kundestyret vault-reference. Standard/Premium får en separat profil-secret; Classic aktiverer HTTPS med en præcis certifikatversion. Hvis det fejler: Ved fejl forsøger rollback at genskabe det tidligere serverede certifikat på det valgte mål. En fejl i gendannelsen rapporteres med backup_dir til videre håndtering.
- Appliance kontrollerer, at målet serverer den nye leaf og hele mellemkæden, med korrekt værtsnavn og gyldighed.
Tekniske detaljer
- Forbindelse
- Pakken kører på appliancen, som forbinder over HTTPS til Azure Resource Manager / Key Vault, port 443. Der installeres ingen agent.
- I skal bruge
- Service principal med tenant-id, klient-id og secret, ARM read/write og operation-statusadgang til profilen/domænet og profilens secrets. Automation kræver vault ARM read, certificate import/get og secret get; secret list ved versionsopslag. Vault skal være i samme subscription. Front Door skal selv have vault-adgang: managed identity eller service principal for Standard/Premium, Microsoft.Azure.Frontdoor med certificate Get og secret Get for Classic. Vault-firewall skal tillade Front Doors adgang via den dokumenterede trusted-service-indstilling.
- Platform
- Front Door Standard, Premium og Classic; discovery vælger API-stien.
- Handlinger
- Discovery, Installation, Kontrol, Rollback
- Pakker
-
azure-appgateway-api1.0.0 - Bemærk
-
- Brug et gyldigt RSA-certifikat med leaf og hele mellemkæden til en rod på Microsofts Trusted CA List, som dækker domænets værtsnavn. Certifikatet skal være et PFX-baseret Key Vault-certifikatobjekt. Appliance skal kunne nå Azure OAuth/ARM/Key Vault over HTTPS og domænets TLS-port.
- Domænet skal allerede være oprettet og have den nødvendige validering og routetilknytning i Azure. Agenten ændrer certifikatbindingen; DNS, routes, origins, identiteter og adgangspolitikker forbliver under jeres administration. Gendannelse til et Microsoft-styret certifikat kan kræve domænevalidering og genudstedelse. Rollback rapporterer fejl, hvis den tidligere leaf ikke serveres inden fristen.
- Management-HTTPS verificeres med systemets CA-tillid. MANAGEMENT_TLS_CA_BUNDLE_BASE64, MANAGEMENT_TLS_PIN_SHA256 og MANAGEMENT_TLS_INSECURE er valgfrie indstillinger. En pin skal matche OAuth, ARM og Key Vault på samme tid; brug CA-tillid ved forskellige certifikater. Tillid til det serverede certifikat vælges separat med AZURE_VERIFY_CA_BUNDLE.
- AZURE_OPERATION_TIMEOUT er som standard 1800 sekunder, AZURE_VERIFY_TIMEOUT 300 sekunder; begge kan øges til 86400. Verifikationen gælder de valgte TLS-prober. Deploy gemmer backup_dir under appliance-datavolumenets HOME til verify og rollback; behold mappen i jeres rollbackperiode. Nye certifikatobjekter beholdes; planlæg oprydning efter jeres rollbackperiode.
- En selvstændig verify bruger den bevarede backup_dir og forsøger at gendanne den tidligere valgte binding, hvis TLS-proben fejler ved deadline, også når ARM stadig viser den nye binding.